Bikerdude: - questions

[Bikerdude]

Morning

 

I have question and request -

• Using the Bind and BindToJoint to attach an existing purse and key, my question is how do I change the position of the purse of key in relation the belt - ie to either moving closer or further away etc..
• Can someone why I am noticable huge fps drop when I enable 'Vsync'
• I need a person or persons who has a low end-ish system to test my map for FPS viability etc and if need be look etc ways of improving fps..

ta.

Edited April 20, 2010 by Bikerdude

[Fidcal]

1. Just literally move/rotate the object where you want it in the editor.

2. Vsync does have a performance drain; that is normal.

3. I have a low end machine but some other tasks so keep me in reserve. I'm sure someone will be glad to check it out but if not then give me a nudge.

[aidakeeley]

Just to add a bit about vsync:

 

To my understanding it works on threshholds. In such a way that it attempts to 'sync' up with vertical refresh by allowing frame rates that coincide. So you get a kind of all-or-nothing set of frame-rate steps. Multiples of say 30, I think for a 60hz rate; Maybe 36 for a 72? So, operating in the first instance, you'll get either 60FPS, or, if it drops below that, it'll drop to 30. Nothing in between.

 

This is basically the understanding I've gotten reading around here lately. Seems to make some sense. Like I say, there has been some discussion in a few threads over the past week.

[Bikerdude]

is there a section in the wiki or beginners guide to unpromising my map for quicker compile times..? My current map is now getting quite big and will get bigger still and I want to build to keep these times as low as possible on lower end machines..

 

I am already doing the many patch's to a func_static app reach where applicable and it helper significantly, but the same approach had the opposit effect when i tried it on a bay window full of worldbrush's.

[Fidcal]

I'm assuming you want to save development time here and not make load time faster for the player.

 

You can do dmap noAAS mapname to save calculating the pathfinding until you really need to. Also remember you don't need to dmap on every change. Just adding or moving a static model or light for instance. But ultimately yes, it does take a long time on bigger maps.

 

You might also try dragging out a giant caulk brush around areas of the map you are not testing. I'm not certain but I think that stops them being processed.

 

More drastically, backup your map, select a huge completed area, save it out as a prefab or possibly as a map, then delete it. Seal off the adjoining areas with a big caulk block. Work with that and restore the other piece at a later date. Personally I would restore it immediately to test I can before proceeding! Also remember, if you go too big (complex) you won't know until you are WAY too big.

[Bikerdude]

I'm assuming you want to save development time here and not make load time faster for the player.

Well initially it was just to make sure load times for the player are short, but I guess speeding up dev time would also be nice.

[Mortem Desino]

I've been looking in the SDK concerning dmap stuff. One thing I can find is generating a mapname.spr (sound propogation file) beforehand, so it doesn't have to generate one on mapload.

 

I don't know HOW to generate a *.spr yet, cuz that wasn't in the documentation. I think a simple internet search should dig it up.

[Serpentine]

I've been looking in the SDK concerning dmap stuff. One thing I can find is generating a mapname.spr (sound propogation file) beforehand, so it doesn't have to generate one on mapload.

 

I don't know HOW to generate a *.spr yet, cuz that wasn't in the documentation. I think a simple internet search should dig it up.

 

It sounds quite interesting, specially if we get some control over how it is done - At the moment large multilayer maps are having issues with horizontal VP's making things sound like they are right next to you in certain situations... cant think of any ideas off hand but a good find never the less

[Bikerdude]

[never mind, bloody DR]

Edited April 22, 2010 by Bikerdude

[New Horizon]

I've been looking in the SDK concerning dmap stuff. One thing I can find is generating a mapname.spr (sound propogation file) beforehand, so it doesn't have to generate one on mapload.

 

Interesting. This is something thief 3 did I believe. Would certainly be helpful.

[demagogue]

On that note, is that something you can customize by hand?

 

Not that it'd be a good idea to change it arbitrarily, but we were just talking about how visPortals direct sound propogation and some of the issues it raises (re: sound going through walls, not always flowing in the right direction, problems with horiz VPs, etc.). If you could actually redirect or cut off sound propagation at some walls by hand, or even in empty air where you want to control its direction or don't want sound going, or some variation on that theme, that could be really useful. Maybe even have a custom function in DR that writes to the .spr file, say with a custom kind of sound-prop-blocking brush; sort of like a monster-clip? And maybe soundPortals to redirect sound.

 

To put it briefly, could that file be a hook for adding features to the sound prop system?

[Bikerdude]

talking of Vp's i would just like them to work when stacked vertically - like they are supposed to....instead of freezing the engine.

[Fidcal]

Visportals work at any angle. If one fails then it is for some other reason.

[Bikerdude]

Visportals work at any angle. If one fails then it is for some other reason.

Well I have found that (and I still dont know why) that if I stack vertical VPs of different shapes and sizes on my current map I either get a stutter as I walk through them or the game freezes completely. And god forbid me if I stack them horizontally, the game will def freeze then.

 

let me ask you this, is it possible to make an invisible wall, that the player and Ai can walk through but I could edge connect a VP to..?

[demagogue]

The invisible part is easy; just use a nodraw texture. As for AI passing through it, not sure. But anyway, note that if there's space between the VP and a wall, everything in the plane from the VP to the wall will be turned into a skyportal. So it might look weird even if it worked.

 

Edit: Though I guess the point of the invisible wall is to stop that. But then that raises the other point that the whole point of a VP is to restrict light flow. So if light is flowing around it, wall or not, I bet it will kill the VP in any event (it's an internal leak). E.g., VPs don't work with objects and transparent textures.

[_Atti_]

I am already doing the many patch's to a func_static app reach where applicable and it helper significantly, but the same approach had the opposit effect when i tried it on a bay window full of worldbrush's.

 

So converting several brushes to a single funcstatic a wrong thing to do performance wise then?

Edited April 23, 2010 by _Atti_

[Bikerdude]

So converting several brushes to a single funcstatic a wrong thing to do performance wise then?

I'm no expert on this, but from what Ive been told and read - good places to do this are where there is the same brush repeated over and over again(eg. a set of stairs) but be careful and don't make the mistake I did and convert a load of brushes (a bay window) to a func_static where the bay window sealed the building it was attached too (as a entity cant seal a room).

 

NB. When I converted a load of patches to func_statics (underground cistern which had 576 patches), I converted into 64x func_static's(each made up of 9x Patches)I didnt see a noticable FPS performance change, but what I did see what a big decrease in dmap time.

 

I'm sure someone who knows whats what will be along to set things straight.

 

[update]

 

when I sealed the inside of the above bay window and converted all 50brushes to a single func_static I got a 5-8FPS hit...

Edited April 23, 2010 by Bikerdude

[demagogue]

It's good for border work around doors and windows, pillars, decoration stuff, etc.

Definitely not for things that will unseal visLeafs.

Try to keep it together.

I went crazy and func_static'd every non-wall thing and it hurt FPS, but then I realized some of it was actually covering up unintentional internal leaks (e.g., between wall and ceiling because the brushwork was complicated.)

Not sure what contribution was from the func_static themselves.

My advice is to try it in waves... Save a new version and func_static the really obvious, small set-piece stuff like non-sealing window & door borders, decorations, etc. Check FPS. Then make a new version and add bigger stuff like ceiling-borders, pillars, etc. Check FPS. Then another wave. Keep going as long as you're gaining FPS; and when you don't, just stick with the previous saved version and it's good to go.

[Fidcal]

It's important to know that horizontal visportals and any angle of themselves are fine; complex arrangements; stacking of visportals, even vertical ones, can be a problem but it is nothing to do with the angle. There is a limit to what dmap can do. At the start of Heart, the entire outdoor area is without visportals because I had to have a complex arrangement of vertical and horizontal visportals - and it kept crashing. No matter what arrangement I had it still crashed - usually as I climbed up and my eyeline was level with the big horizontal visportals. It's nothing to do with them being horizontal though; but it is everything to do with the complexity of many visportals arranged together going far beyond what the doom 3 code intended. If you turned any normal well-visportalled FM on its side so most visportals are now horizontal, it should still dmap OK (assuming no other problems!)

 

Turning lots of small details into a func_static, especially one composite item like some open wooden stairs, is good. Turning a multi-piece window into a func_static is fine and is recommended. The same with a doorframe. Whatever. Once these are created and dmapped I believe the compiled func_static is stored in a file and works similarly to a model in that it doesn't need dmapping again. So, you can grab your func_static stairs, window, whatever, and move it and you don't need to dmap it even though you have completely changed the position of your brushwork. (it does get dmapped I think anyway next you have to dmap something else.)

 

That said, whenever you divide up your map into sections using visportals then as you know the visportals must seal worldspawn. So, if you made a brush doorway into a func_static then a visportal in that doorway must cut right through to the worldspawn. If you made a func_static window out of brushes and it cuts right through a wall into another area then you need to seal that hole just as you would if it was a model. If it is an opening window or glass then use a visportal. If it is a static opaque window then seal it internally with a panel of caulk. It then exists as a worldspawn building with a section of wall that is caulk with a func_static sticking through it. The only disadvantage there is that the func_static is rendered both sides so it might be best to split the window into two func_statics - inside and outside sandwiching a caulk panel in between. (minimum thickness I can never remember, maybe 1 unit. Try it. Leaks go right through solid stone if it is too thin.)

 

One way of checking what you are doing is to use Dark Radiant's filters to filter out all entities and all patches. What is left is worldspawn and it should all be sealed into sections either by solid textures, caulk, visportals, whatever. If you see a doorway with a visportal floating in the middle not reaching the edges then resize it to fit. Same with a window opening. Everything should completely visibly sealed. Any visible gaps or glass, seal them.

[Bikerdude]

Also, add this to every AI:

 

max_interleave_think_dist 1000

min_interleave_think_dist 240

 

can the above figures be changed to make the Ai think even less, to reduce FPS drop...? I ask because when 1 or more Ai go outside I'm noticing a 5+ FPS drop per each Ai on my map..

Edited April 23, 2010 by Bikerdude

[Fidcal]

By 'outside' you mean come into the player's area? Thinking optimisation is disabled in the player's area anyway no matter what the values. It only works when they are out of sight. In Heart on 'Easy' level, I removed several AI from one busy area so it would work better on low end PCs.

 

Another optimisation you can use, but again, it only works on AI that are out of sight, is neverdormant 0. I think that is doom 3 default but in Dark Mod we have it set to 1 so they are never dormant. Instead we have the thinking optimisation. This is because if they go fully dormant then they freeze in the same place until the next time you see them. But this is OK for select AI, eg, a static sentry or where it is not obvious. I have this set on a few AI in Heart. Note that they will not go dormant if they are alerted first so if you are being chased by a guard and go through a visportal door and shut it, he won't freeze outside but still come after you!

 

But this won't help you if your problem is a lot of AI in one open area. All you can do is design your FM to limit that as much as possible.

 

[EDIT] BTW here is the wiki article on thinking optimising...

 

http://wiki.thedarkmod.com/index.php?title=Interleaved_Thinking_optimization

[Bikerdude]

Another question:

 

Why is it with TDM that when the FPS drops below the 45 mark, the games becomes micro stuttery..? and this stutter gets worse the lower the frame rate goes. I have tested this with Vsync off and on and its the same in both. Also I've noticed this on every Fm I've played. Other games I have played don't have this issue, so is it something thats inherant in the Dm3 engine or am I missing somthing obvious about my computer setup...

 

CPU - Intel Qx9650@3.0Ghz

GFX - ATi HD5870@stock - Cat 10.3 def setting, w/Ai off

MEM - 4GB DDR2_1066

SOUND - XFi xtreme music - 2.18.0013

Mon - 20" NEC 20wgx2pro -1680*1050@60Hz

HDD - Raid-0 Seagate 320GB*4 - 450MB/s (read&write)

PSU - 1KW Nexus RK-1X

OS - Win7ultimate x86

 

Is there some setting Im missing or hardware issue with DM3 that i should know about -

 

- this issue is seriously ruining my game-time.

Edited April 24, 2010 by Bikerdude

[Serpentine]

In ID engines - A _lot_ of "unrelated" stuff relies on the fps, in doom3 with the addition of more physics and TDM's advanced AI, lighting and such this time although minimal for the most part becomes pronounced when it gets outside of its comfort zone, its actually much more noticable on higher end hardware due to the inherent difference in waiting and rendering times, while on older machines it seems less jittery because both the render and the processing is slowish. Its very noticeable when you alert AI however.

 

I guess with optimization of the AI and general code cleanup you could get rid of some, but its hardly a certain fix and it would be very time consuming. If you know of any devs that want to join the project please send them this way

[Springheel]

Why is it with TDM that when the FPS drops below the 45 mark, the games becomes micro stuttery..? and this stutter gets worse the lower the frame rate goes.

 

I've never experienced this myself. In fact, I've found that TDM is oddly playable even at FPS rates that seem quite low.

[Bikerdude]

, its actually much more noticable on higher end hardware due to the inherent difference in waiting and rendering times, while on older machines it seems less jittery because both the render and the processing is slowish.

Hah, bloody classic.... This has got to be one of the few times when my system is too powerful.... hmmm this is sounding an awefull lot like T1/2" and the issues that has running on DX10 or higher gfx cards...... I wonder if we will have to make a 'wrapper' for tdm...

 

....er, hang on ID tech 3/4 is OpenGL and I thought that was universal..?

Edited April 24, 2010 by Bikerdude