Bikerdude: - questions

[Bikerdude]

I want a boat that swings and bobs -

Edited October 4, 2010 by Bikerdude

[nbohr1more]

!!!

 

(Please let this FM arrive soon... If this is another one that is pending some awesome v1.03 feature, I will go completely bonkers... )

[Fidcal]

As MD says, use bind. In your case I would say, make the boat a func_bob whatever that is and bind it to a nodraw func_pendulum. Or the other way round.

[Bikerdude]

As MD says, use bind. In your case I would say, make the boat a func_bob whatever that is and bind it to a nodraw func_pendulum. Or the other way round.

yeah while waiting for a a replies that idea came to me - now Im just trying to tweak so the movies look sorta random...

 

And on that subject is there a way to randomize the bob and pendulum swing...?

[Fidcal]

My first thoughts are to set two trigger timers, one to target each. I think each time it firest it toggles on/off. There is likely a random time for it to trigger. If so, it's most likely something like wait 2 seconds (or 2000 milliseconds) then rand or random 2 which would be plus or minus 2 off the wait so it would trigger every 0 to 4 seconds.

[Bikerdude]

sweet, Ill have a go at that when i get home..

[Tels]

And on that subject is there a way to randomize the bob and pendulum swing...?

 

You would need to write a script for that. Also file a tracker entry saying that you want random movement of a model (albeit atm we are a bit bsy so it might not get worked on for a while)

[Bikerdude]

Another question:

 

Sats asked me what the poly scene limit is for DR/TDM like said limit in Dromed, is there even a limit - or is more a case of designing your map for your target audience's hardware like I do with my maps..?

[Baddcog]

more hardware specific.

 

I've had at least 60,000 polys on screen with one ai, 60 fps (my old gfx card). I know others have pushed over 100,000+

 

of course if those were all lit and casting shadows it might get ugly.

[Tudor]

Isn't basically every stencil shadow an additional same set of polygons as the mesh it gets it's data from? So if you have a shrub of 2000 polies and it recieves full shadows from one light that would be 4000 polygons?

[SneaksieDave]

As BC said, I don't believe there is any limit, just how much the hardware can handle. Early (like, 2004), I made a crappy city test map (no portals, no AI, etc) and I had a quarter of million polys on screen on my old system (1.4GHz, GF Ti4600) at maybe 15-20 FPS, IIRC. Not great, but not bad. I'd guess some of the scenes in Doom3, with all the patches and models, probably averaged 40k-100k regularly. Use of performance tricks (disabling some shadows etc) help there of course.

[nbohr1more]

Yeps...

 

The only limits are the Entity Limit (8192) and Event Limit (8192) AFAIK... (And there may be upcoming stuff that breaks even those limits?) But right now, as you have seen, 4000 entities is a more practical limit due to complexity issues...

 

One entity could have thousands and thousands of polys though...

[Bikerdude]

You would also need to use this switch "/LARGEADDRESSAWARE" for the application itself:

 

There is a multi-part article about the problems that applications were having for the transition to 64bit memory addressing:

 

A Messy Transition Pt 1 at Anandtech

 

As I have both the 32/64bit versions of Win7, is it work my time installing the 64bit as well as putting the "/LARGEADDRESSAWARE" on my TDm shortcut..

[New Horizon]

Yeps...

 

The only limits are the Entity Limit (8192) and Event Limit (8192) AFAIK... (And there may be upcoming stuff that breaks even those limits?) But right now, as you have seen, 4000 entities is a more practical limit due to complexity issues...

 

One entity could have thousands and thousands of polys though...

 

The original limit was half of that. We increased it some time ago. It should provide a high enough ceiling for some time.

[Tels]

There aren't really "limits" in the idTech3 engine, except:

 

* 8192 entities at most

* I think 10000 render entities at once visible

 

I have created maps that push 6 million polies just fine, albeit the performance isn't stellar. It mainly it depends on how many lights are hitting them, and how many of them are casting shadows, and how many entities represent these polies.

 

Each entity * each light hitting it => one drawcall. So if you have 1 entity hit by 1 light (the ambient light), but representing 6 million polies, it will render it in one batch. If you have 10 entities, and each is hit by three lights (ambient, a fog light, the player lantern), then you suddenly have 10 * 3 = 30 drawcalls just to render the same scene and this will slow things down.

 

So, to optimize your map:

 

* reduce the tris count first (use little detailed entities, remove entities, use LOD stages)

* then batch everything up into as little entities as possible (combine things into one func_static)

* then reduce shadow casting lights and entities that cast shadows (or simplify their shadow mesh) as much as possible

* then sep. your maps into visportaled rooms, so not everything is visible at once

 

However, what is "optimal" varies greatly with the hardware. Modern CPU+modern GPU can push an insanely high amount of polies, but since D3 is CPU limited, the shadow count will probably kill your performance.

[Sotha]

* then batch everything up into as little entities as possible (combine things into one func_static)

 

 

Hmm. A stupid question, if you will:

you talk about entites. Is worldspawn an entity? I mean: does worldspawn as a whole result in one drawcall? Or is each worldspawn component one drawcall?

 

Also please comment the following statements:

 

• A good rule of the thumb is to have all decorative brushwork(*) in a standard sized room as a single func_static. (*)decorative brushwork means beams, windows, everything not sealing against the void.
• Or should the room decorative brushwork be set as multiple entites on each side of the room. I mean north wall windows, trims, etc are one func_static and south wall decorations a different func_static. When considering visportal operation I'd think this kind of consideration would be wise.
• Both statements include proper monster_clipping

I'm very interested on this topic since, I've just recently been thinking about optimizing, but I'm unsure how to do it. I want to learn the correct workflow.

[Bikerdude]

As I have both the 32/64bit versions of Win7, is it work my time installing the 64bit as well as putting the "/LARGEADDRESSAWARE" on my TDm shortcut..

So...?

[Tels]

Hmm. A stupid question, if you will:

you talk about entites. Is worldspawn an entity? I mean: does worldspawn as a whole result in one drawcall? Or is each worldspawn component one drawcall?

 

worldspawn is an entity, entity #0 (or #1, I don't know exactly, but it is the first entity). Not sure, but I believe it is drawn in one drawcall. It is also used for AAS (pathing and collision) and the more complex it is, the slower things get. So ideally you have only a "very flat, boxy" level if you hide all entities.

 

Also please comment the following statements:

 

• A good rule of the thumb is to have all decorative brushwork(*) in a standard sized room as a single func_static. (*)decorative brushwork means beams, windows, everything not sealing against the void.
• Or should the room decorative brushwork be set as multiple entites on each side of the room. I mean north wall windows, trims, etc are one func_static and south wall decorations a different func_static. When considering visportal operation I'd think this kind of consideration would be wise.
• Both statements include proper monster_clipping

 

I'm very interested on this topic since, I've just recently been thinking about optimizing, but I'm unsure how to do it. I want to learn the correct workflow.

 

When you combine things manually into one func_static, combine as much as possible into one entity, but not too much. E.g. north wall, south wall, all should be their own entity due to the "air gap" sep. the different pieces.

 

The reasons why you should not combine are:

 

* different materials. If you combine a wood beam and stone column, you don't gain much, as they will result in two drawcalls, anyway. What you gain is one entity, e.g. a tiny bit of memory, a tiny bit of CPU resource not to spawn another entity etc. However, these are only very small and should only be done if you really need to conserve entities.

* entities that would cross a visportals. Thats bad because they are now part of two areas and are render in both, even when the player can only see one half of it.

* things that create a big, sparse volume. (Thats only a guess tho) The reason is that many culling operations check against the bounds first. Imagine you combine a few wood beams on the south wall with the beams on the north wall. While this might improves rendering performance (if both walls are visible), the collision detection would always consider anything inside the room to be in the same bounds as the entity, and then need to check if it really collides with any of the parts. If you have two entities, one left, one right, their bounds are much smaller, and a moving entity (AI, player etc) would not be in their bounds when it moves in the center of the room. So, this needs a bit experimenting, but the effect might be too small to see in normal levels. But it can be important in caves, churches etc where you have a huge room and an entity that is huge, too. Then basically on every step the AI would "collide" with every thing that is in the church at once, or with any piece of the cave floor at once.

 

Also, if the player views only one wall the entire combined entity gets rendered, if you have two, the engine could cull the one half that is behind the player.

 

A lot of this stuff is experimenting, tho.

[nbohr1more]

I would give it a try Biker.

 

For Dark Radiant your map should compile down to much less resources in most cases but you could end-up creating something too large for 32bit without noticing...

 

For Doom 3 it may give you the ability to compile larger maps. You could end-up creating a map that will only dmap on a similarly configured environment so 32bit end-users might not be able to dmap for trouble-shooting purposes.

 

But it's not usually a bad thing to be over-powered. Look at the game studios that use a super-computer to pilot their games until the consumer hardware is fast enough.

[Sotha]

Thank you Tels! I'm almost fully satisfied by your answer.

 

A lot of this stuff is experimenting, tho.

 

It's probably not realistic to think mappers find optimal degree of func_statification via trial and error, but one good easy-to-learn rule of a thumb would probably help people on the right track.

 

Then the following:

* then batch everything up into as little entities as possible (combine things into one func_static)

 

would transform into something like:

 

Make multiple brushes of the same material or duplicate objects in relatively close proximity of each other into combined func_statics. Do not let the func_statics cross visportals.

 

On pathfinding, one question:

Having a worldspawn brushes increase pathfinding complexity. How changing worldspawn brush into a func_static and then applying monster_clip in the func_static reduces pathfinding complexity? Intuitively one might think the situation remains the same whether it is worldspawn or func_static with monster_clip.

 

That's all I'm gonna ask, I promise! And sorry Biker, for hijacking your question thread for my own questions.

[Baddcog]

the monster clip is really just to keep ai from walking into, getting stuck on/clipping thru func_statics.

 

So it doesn't simplify pathfinding per se, just keeps ai from getting stuck walking into the details they don't know are there.

 

I use it to narrow corridors and doorways. that way on random patrol they might 'scrape' against the monster cilip to go through doors, around corners. but to the player it looks like they are aiming for the center of doorways, or just trying to stay away from scraping walls.

------------

@biker

 

I'm using 64 and have no probs at all...but all the techno mumbo jumbo, i have no idea

[ungoliant]

So it doesn't simplify pathfinding per se, just keeps ai from getting stuck walking into the details they don't know are there.

 

are you sure about that...? if the pathfinding stayed the same, wouldn't the AI just keep trying to walk through the monsterclip and get stuck on it same as with models etc?

[Baddcog]

Are you sure you read what I wrote?

 

Basic level geometry even with tons of func_statics has about as simple as pathfinding as it can possibly have. adding monster clip actually complicates it more.

 

without func_statics and objects the terrain (ie pathfinding) is a very basic set of hallways. but when you add clip around objects, func_statics, etc... there's a good chance you are actually adding more shapes to the pathfinding data base, thus naking it more complex.

 

say yu have a hallway with a lamp in one corner. without monster clip its a big rectangle. with monster clip it's most likely now a large rectangle with a square cut out of it.

 

I didn't say monster clip had no effect.???

[Fidcal]

No, because pathfinding is calculated from worldspawn. Monsterclip must be worldspawn to work. So in a room with lots of entities of complex shapes whether models or brush/patches, simplify all that with monsterclip around them. Don't worry about close fitting every detail but also don't waste any horizontal space. Check out the before and after screenshots below:

 

 

 

[edit] Notice that there is no need to leave gaps in every little crevice between chest and chair and in corners. No need for AI to go there and get stuck. And if the player is there inside the monsterclip the AI can still hit him so long as he is within range.

[Bikerdude]

er hi-jacked thread much...

 

As I have both the 32/64bit versions of Win7, is it work my time installing the 64bit as well as putting the "/LARGEADDRESSAWARE" on my TDm shortcut..