News:

One Minute Game Review by The Happy Friar: https://ugetube.com/@OneMinteGameReviews
Also on Rumble: https://rumble.com/c/c-1115371

idTech 4 (aka Doom 3 tech) Discord Server! https://discord.gg/9wtCGHa

Main Menu

LOD system

Started by argoon, November 23, 2016, 10:08:21 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

argoon

#30
Quote from: motorsep on December 08, 2016, 11:21:38 PM
Why do you even use deform sprite ? Just make grass model with crossed planes and that's all. They don't need to "look" at you as you move. Just use regular material without deform sprite.

Yes i know that and it would even make me use a single material for all (that would bring the draw call's down even more) and i'm planing to have lod0 and lod1 be cross planes but i want to have the ability to have at the long distance "impostors" and those are flat planes, if i don't use deform sprite or a similar lookAt function they look odd.

Quote from: BielBdeLuna on December 09, 2016, 05:23:12 AM
so every grass has a loop in script? every entity has a loop that runs every frame within the c++ code, look for the "think" function, you could code this in c++ and so you would not waste resources in the scripting side, you can also look into how The Dark Mod implemented their LOD system too.

Yes every grass object has a loop in script if you know how to make it otherwise (make it so they don't "think" all at the same time) and tell me i would be very grateful.
About the engine code again my c++ knowledge is very limited, i know it sounds like i'm afraid of going to the engine side (and i'm a little) but in reality i don't want to mess with fhdoom engine source, for the simple reason that, is more complicated code and if eXistence updates the engine, my code changes could make it impossible or very hard to update to the new version, if i can do it in script, better, if not i try other stuff, i'm just experimenting and learning for now.

Btw i changed the script so the loop runs only if the player is moving if not the loop stops, improved performance even more.



Edit: For anyone using notepad++ code editor i made a custom language highlighter for idtech4 script, here, anyone can edit it, so be carefull, the colors are for a dark theme tho but you can easily edit them in the notepad++ user language editor , is not fully complete (you can help) but most of the script functions are there, there's also custom coder keywords like TODO: , NOTE: , WARNING: , to help organization, to use them just write the keyword after single/multi line comment like so ex: //NOTE: "my note"  and it will work, i also made a (very incomplete) code auto complete/auto function helping here, but unfortunately it doesn't seam to work and i don't know why.

argoon

#31
My grass system work's for the most part, performs very well and everything but unfortunately still flickers like crazy,  :-\  i tried everything i could, i changed my script perhaps 5 times, i tried changing models at run time with setModel(), spawning and removing the models at run time with spawn() and remove(), this one gave me the option to use plenty of grass entities in a level, but unfortunately performance was not that great in the end i settled in a spawn all and hide at init(), this last one gets me the best performance, unfortunately eats the entity budget fast if i'm not careful.

About the grass material i use now the "real translucent" technique found by TDM developers and my grass now looks very nice and reacts to light and shadows. :) Happy on this at lest.


The Happy Friar

What if instead of each grass object running the script you have the player run the script against a known # of grass objects & it changes them that way?  You'd only have one thread running then.  Would be a little more complex to setup though.

argoon

#33
Quote from: The Happy Friar on December 10, 2016, 09:06:33 PM
What if instead of each grass object running the script you have the player run the script against a known # of grass objects & it changes them that way?  You'd only have one thread running then.  Would be a little more complex to setup though.

Yes that is a nice idea!! I could just "tag" the grass objects and make the player detect them at run time, in my head the code wouldn't need to be very different, i would just run the loop on the player script instead of on every grass object, but i could be thinking wrong, need to experiment and see. Now that i think about it, that is how BielBdeLuna made his frob highlight script that he generously gave us!

Btw i assume this will not solve the flickering problem but i hope i'm mistaken.

The Happy Friar

If you're getting flickering in stock D3 but I can load  & change between random entities (even ones not cached) w/o flicker, it's got to be a CPU/threading thing or something in the engine changed that broke that ability.

Also try to do the grass in groups.  So instead of a single model it's 10 grass models.  Would cut down on what to check for.

argoon

Quote from: The Happy Friar on December 11, 2016, 12:41:47 PM
If you're getting flickering in stock D3 but I can load  & change between random entities (even ones not cached) w/o flicker, it's got to be a CPU/threading thing or something in the engine changed that broke that ability.

Also try to do the grass in groups.  So instead of a single model it's 10 grass models.  Would cut down on what to check for.

Thanks i will if the suggestion about running the code on the player don't pan out, btw so i assume you tested my code and it worked?

The Happy Friar

haven't had time to test, I was basing it on my previous experiments with loading random entities.

bitterman

#37
Can't believe that idtech4 haven't the LOD. Even a Quake 3 engihe has it (but perhaps it was added to native engine by Raven).

Idtech4 have a image_lodbias CVAR which is control a texture detalization.

Maybe is there no need to make few same models with different level of detail because id4 engine have some alternative feature instead LOD?


motorsep

While idTech 4 doesn't have it, Storm Engine 2 does ;) Check source on github

The Happy Friar

q3a did?  I don't remember it in the stock game.


LDAsh

LOD you don't notice is LOD done right, at least visually.  It was used for characters and patch-meshes.  idTech4 only for patch-meshes, which always gave me hope it could be more widely implemented.  AFAIK, both SS2 and TDM implementations are "streaming" the assets in from the HDD, and not already residing in the vertex-buffer.  This may not have the performance hiccups it once had if everyone has an SSD now, but it's still not practical for broad use.  It would work well enough in your average tech-demo box map, but not for an expansive open-ended forest environment.  This whole thread has pretty much covered how and why.  It would need to do something like shove all of the stages into the same MD5.  As it is, it's only good for a handful of the most complex meshes.

bitterman

#41
Quote from: The Happy Friar on January 26, 2021, 09:35:13 PM
q3a did?

Well, Jedi Academy did (I think).

And I see something similar in the description of IDTech7.

Quote from: LDAsh on January 27, 2021, 01:37:53 AM
idTech4 only for patch-meshes

What do you mean? Some feature in engine (without moddeller's work)?

************upd **********

About Jedi Academy LOD:

const int maxLod =Com_Clamp (0,ghoul2[0].currentModel->numLods,3); //limit to the number of lods the main model has


/*
=================
R_ComputeLOD

=================
*/
#ifdef _XBOX
int R_ComputeLOD( trRefEntity_t *ent ) {
#else
static int R_ComputeLOD( trRefEntity_t *ent ) {
#endif
float radius;
float flod;
float projectedRadius;
int lod;

if ( tr.currentModel->numLods < 2 )
{ // model has only 1 LOD level, skip computations and bias
return(0);
}

// multiple LODs exist, so compute projected bounding sphere
// and use that as a criteria for selecting LOD
// if ( tr.currentModel->md3[0] )
{ //normal md3
md3Frame_t *frame;
frame = ( md3Frame_t * ) ( ( ( unsigned char * ) tr.currentModel->md3[0] ) + tr.currentModel->md3[0]->ofsFrames );
frame += ent->e.frame;
radius = RadiusFromBounds( frame->bounds[0], frame->bounds[1] );
}

if ( ( projectedRadius = ProjectRadius( radius, ent->e.origin ) ) != 0 )
{
flod = 1.0f - projectedRadius * r_lodscale->value;
flod *= tr.currentModel->numLods;
}
else
{ // object intersects near view plane, e.g. view weapon
flod = 0;
}

lod = myftol( flod );

if ( lod < 0 ) {
lod = 0;
} else if ( lod >= tr.currentModel->numLods ) {
lod = tr.currentModel->numLods - 1;
}

lod += r_lodbias->integer;
if ( lod >= tr.currentModel->numLods )
lod = tr.currentModel->numLods - 1;
if ( lod < 0 )
lod = 0;

return lod;
}


LDAsh

In Q3A you can play with the "r_lodbias" command to see for yourself.
For Quake 4, there are various LOD cvars.  I got confused because Doom3 is missing a lot of features that Q4 had, so when I say idTech4 I'm likely thinking about Q4 over D3.

I's been well over 10 years ago now...

The Happy Friar

huh, q3a actually does have lod.
what the heck is the distance though?  On dm17 I can go to the rrail gun, zoom in on the RL and it's still the same model as when I'm right next to it.
Maybe it was just used in the expansion pack?  Or maybe when X poly's are on screen?

LDAsh

Every LOD system I've seen accounts for zoom/FOV, and many of them account for screen resolution also.  You might want to try r_showtris if you really want to see it in action.