Things that could be improved

[ocn]

Well, there could be a selection of rooty clumps one could attach at will if needed. I'm not that comfortable with patches and such yet. If the bottoms were just closed, it would help alot.

Edited January 10, 2011 by ocn

[demagogue]

There are other models that have missing faces too. Patches are a good general solution. And it's good to learn the fine art of using them eventually.

 

But anyway, what somebody could do in this case is make a bottom out of patches and then upload it as a pre-fab, with the tree already attached, for others to take and use (and eventually for the other models). Seems like the best idea to me, and is essentially what you're asking for in effect.

 

(And while they're at it, it would be fun if people started making all sorts of attachments for objects attached to them as prefabs. Then people know where to look for this kind of thing and they're all kept together, and starts the trend of using patches for this kind of thing than making a new object every time.)

[ocn]

(And while they're at it, it would be fun if people started making all sorts of attachments for objects attached to them as prefabs. Then people know where to look for this kind of thing and they're all kept together, and starts the trend of using patches for this kind of thing than making a new object every time.)

 

That's a terrific idea!

[i30817]

The game does have occlusion culling right?

[Serpentine]

The game does have occlusion culling right?

 

Nope, not true static occlusion culling.

[Aprilsister]

Fake static occlusion culling?

 

What is the world coming to!?

[Serpentine]

Fake static occlusion culling?

 

What is the world coming to!?

 

There are loads of different ideas, methods and similar concepts blanketed under "occlusion culling". Doom3 will cull rendering geometry which is both occluded and lit by a light volume which is also occluded (this cant happen in TDM, and in general doesnt seem to happen anyway). Since it's using BSP and z-ordering does cut out a lot of surfaces which are occluded, but as I've been noticing through profiling, it's really a low percentage of things in comparison to what you would expect, one of the reasons is that internal faces and such of models or other entities are not taken into consideration and as such need to be caulked. To me these techniques don't quite cover the concept of occlusion culling.

 

You can also consider BSP as a form of occlusion culling depending on how you deal with portals, for example doom3 will cull the rendering of a leaf which has a completely occluded portal (in most cases), do you call this "Occlusion Culling" or not? Semantics sure are fun. A lot of games use similar concepts and generate vis data in a pre-process, hinted by mappers if there are problems.

 

Then you get dynamic culling, a bit like the fancy version offered by the middleware outfit Umbra Software, if you dig around there used to be a demo of an RPGish city which showed it off quite well.

 

So where do you call it? Kind-of? implicit? when conditions are right?

[Aprilsister]

Yeah, I was just having a bit of outsider fun with the xeno-lingo...

 

But I do appreciate the explanation. That's also part of what I hope to solicit. So thanks!

 

So there!

[Serpentine]

And hey, that blanket sure is damn huge...

 

http://en.wikipedia.org/wiki/Occlusion_culling

 

Seems semantics be damned, we're pretty much covered in the stuff according to that... I still think the contemporary idea of more dynamic culling is what is often intended.

[Aprilsister]

Well whatever becomes of TDM, when the tshirts finally do come out "Fake Static Occlusion Culling" is another fine candidate for the manditory text-on-the-back-of-the-tshirt.

[Aprilsister]

A quick one & hopefully a quick "fix" possibility:

 

While playing a bunch lately somewhere along the way I swear I saw a clock on one of the TDM menus... didn't I? With current time and date... quite a good thing for those of us who might play waaaaaay tooooooooo lonnnnnnnnnnnnng sometimes. So I would request this be put on all the menu screens. Thanks.

 

...

 

Found it on the Save/Load screen. Very nice.

 

...

 

Well I this at least got me to looking into the guis... and finding no satisfaction there... search the code a bit... only to finally snap to and realize that the reason I hadn't always noticed it? Is because it's not really a clock/calendar... just a "stat" for the selected FM... I've been doing a lot of saving (~20GB worth) for the alpha of Manor Royale, so I come back in after a quicksave to make a real save often and it functions like a current clock for the way I'm going about things

Edited January 15, 2011 by Aprilsister

[nbohr1more]

Yeah, I was reading an old Beyond3d interview where they grilled John Carmack about overdraw because they are Tile-Based Deferred Renderer fanatics and have been rooting for the PowerVR approach for ages. Carmack seemed to shrug at the idea of doing extra work for over-draw reduction beyond BSP. I got the impression that he thought that was ATI and Nvidia's job. Then he poured a little salt on the PowerVR fanboys' wounds by saying he might look at making a Doom 3 render path for the chips if their OpenGL drivers were top notch.

 

Unless someone up there with a real great math noodle can figure out an really really efficient visibility detection algorithm to add to either LOD or SEED... the issue will need to be address in the renderer (GPL).

[spiney]

is it possible to make broken arrows not disappearing?

[Fidcal]

Yes,

 

for a static arrow create a model under models/darkmod/junk/ and you will see several like broadhead_broken1.lwo

 

for a moveable arrow create an entity. look under moveables/junk

 

 

[EDIT] Wait, I thought this was an editing question. Is it? If not then you mean in Dark Mod generally you'd prefer that arrows don't disappear?

[7upMan]

If that's what spiney meant, then I second that idea. I always thought that it's a bit unrealistic if broken arrows just vanish. Or, if they must, then they should vanish after a few minutes, not almost instantly. Is there any cvar for this?

[Fidcal]

Not sure what the timeout is. Maybe it varies as to whether they are from the player or the AI. This is a screenshot I took some time ago and these arrows must have lasted quite a few minutes to build up.

 

[Aprilsister]

Those look like unbroken retrievables...?

[New Horizon]

He was talking about broken arrows, and I'm sure they could be made to not vanish...but I think the reason they were allowed to vanish was so they wouldn't contribute to the entity limit. They just go splintering off anyway, and they're useless, so it doesn't make sense from a game perspective for them to stick around. I understand the realism argument, but it's not really that huge a deal is it?

[spiney]

7upman that's what I meant, yes

Fidcal not editing, just to increase the timeout

[Fidcal]

Those look like unbroken retrievables...?

Ah of course. I used to taunt the guards just out of their range. That was before the gate was openable of course. What a sad git.

[Tels]

He was talking about broken arrows, and I'm sure they could be made to not vanish...but I think the reason they were allowed to vanish was so they wouldn't contribute to the entity limit. They just go splintering off anyway, and they're useless, so it doesn't make sense from a game perspective for them to stick around. I understand the realism argument, but it's not really that huge a deal is it?

 

Btw, I do think the more compelling argument back than also was "performance". These days (and even back then with some tricks) it would be possible to make all broken arrows in the same PVS belong to the same entity and render them all in one go. So it would render a lot faster and not count (much) against the entity limit.

 

However, this is a LOT of work just for such a small effect.

 

I do agree with others, tho, the pieces could stay around a bit longer, the arrows the player has are pretty limited and he can't bring his system down with them anyway.

 

(One thing to consider is AI, tho, if you have an archer pummeling you with arrows and they last for X minutes, we must ensure that there aren't so many that the entity limit is reached. However, in that case archers could switch to throwing stones

[New Horizon]

 

(One thing to consider is AI, tho, if you have an archer pummeling you with arrows and they last for X minutes, we must ensure that there aren't so many that the entity limit is reached. However, in that case archers could switch to throwing stones

 

Then folks will complain the stones don't stay around.

[Tels]

Then folks will complain the stones don't stay around.

 

 

The funny thing is, I always dream that it should be possible to have really 100000 "objects" in a game, and the computer not breaking down. Would be so awesome if that stuff could just pile up. Instead D3 slows down to a crawl just because you break a brittlefracture into 1000 parts *sigh*

[spiney]

Btw, I do think the more compelling argument back than also was "performance". These days (and even back then with some tricks) it would be possible to make all broken arrows in the same PVS belong to the same entity and render them all in one go. So it would render a lot faster and not count (much) against the entity limit.

 

How much is this entity limit??

btw, the texture from exploded mine should stay longer too =)

[Tels]

The entity limit on stock D3 is 4096 entities, on TDM it is 8192.

 

From this you have to subtract a few always-existing entities (worldspawn, player, weapons), and resevere some for dynamic things like spawning absence markers, blood etc.)

 

While technically the entity limit could be raised further, there isn't much sense in doing so, because each entity needs memory and spawning entities takes a lot of time, too. If you create f.i. a map with over 4000 entities, it will already be quite big, need a long loading time and also might suffer from poor performance due to rendering such an amount of entities.

 

The engine therefore does a few tricks - like particles are not entities, instead all particles belong to the same entity. Likewise for glass shards from breaking windows, or smoke. I guess the same could be done with our arrow broken parts (once they stabilized and do no longer move), but this is quite a lot of work to restructure the code just for that.