Hello guys i made a LOD system for my mod using script and it works, more or less, the lod change works the problem i'm getting is that when the model changes it shivers for a moment and is very obvious, do you guys have any idea on how to smooth that transition?
here is the script code
/***********************************************************************
lod_object_base.script
self script contains any LOD's specific code.
revision = 0.1
***********************************************************************/
#define LOD_LEVEL_0 1
#define LOD_LEVEL_1 2
#define LOD_LEVEL_2 3
object lod_object_base {
// bool to control the while loop
boolean isON;
// lod0 position for the other lod's
vector currObjPos;
float currentLOD;
string lod0_model;
string lod1_model;
string lod2_model;
// player entity
entity lod_player;
// enable or disable the LOD check, no need to do it on objects with no lod's
float lod_enabled;
// show distances
float lod1_dis;
float lod2_dis;
// player distance from lod object
float pldistance;
void init();
void lodUpdate();
void checkLOD();
};
void lod_object_base::checkLOD() {
pldistance = self.distanceTo(lod_player); // check lod obj pos distance to player1 pos
if( pldistance < lod1_dis && currentLOD != LOD_LEVEL_0 ){
currentLOD = LOD_LEVEL_0;
self.setModel(lod0_model);
}
else if ( pldistance >= lod1_dis && pldistance < lod2_dis && currentLOD != LOD_LEVEL_1 ){
currentLOD = LOD_LEVEL_1;
self.setModel(lod1_model);
}
else if ( pldistance >= lod2_dis && currentLOD != LOD_LEVEL_2 ){
currentLOD = LOD_LEVEL_2;
self.setModel(lod2_model);
//self.setKey("noShadows", "1"); doesn't work at runtime :(
}
}
/*
============
lod_object_base::lodUpdate
============
*/
void lod_object_base::lodUpdate() {
lod_enabled = self.getIntKey("lod"); // get the spawn lod value
// if spawnarg lod is 0 disable the while loop
if(lod_enabled == 0){
isON = false;
}
// gets the lod0 world position
currObjPos = self.getWorldOrigin();
// not run this on the loop or it will not work.
currentLOD = LOD_LEVEL_2;
// get the models can be set on the editor if using the def key "editor_model"
lod0_model = self.getKey("model");
lod1_model = self.getKey("model_lod1");
lod2_model = self.getKey("model_lod2");
// then get lod distance values
lod1_dis = self.getIntKey("lod1_distance");
lod2_dis = self.getIntKey("lod2_distance");
// this gets the player entity
lod_player = sys.getEntity("player1");
// runtime loop to check for the player position and set the lod objs
while ( isON ){ // while isON == true
if( lod_enabled ){ // if lod0 has the spawnarg lod_enabled with value 1 then run if not stop
checkLOD();
}
waitFrame();
}
}
/*
===============
initialisation
================
*/
void lod_object_base::init()
{
waitFrame();
isON = true;
thread lodUpdate();
}
Model switching should be instantious, not sure what you mean by a "shiver."
Yes is true is instantaneous, when i said shivers is not really accurate is more it flickers like the material gets lighter then darker again, will try to make a video and show it.
Ok here is a video.
https://drive.google.com/open?id=0B_xD8k_3dkNpa053MXFiRUhwREk (https://drive.google.com/open?id=0B_xD8k_3dkNpa053MXFiRUhwREk)
looks to me like for a game frame the model dissapears & the new one appears the frame after, so there's a blank model there. Or the models are in the same space & some kind of fighting going on there.
Try using the avidemo/game command @ 60fps & it might be easier to see if it's having a blank space or fighting visually. com_avidemotics 4 should record the demo @ 60fps.
Thanks for the hint, yes the models are in the same space, they should be i'm just swapping the visual model for the entity, visually they are the same object but with LOD levels (less geometry for the lod1 and lod2), i will go experiment with that command and see what i find, thanks for the help. :)
edit- Yep you were right there's indeed a empty frame between the model swaps, when swamping to different unrelated models is not obvious but when used on a real LOD it is, how can i solve that? Is the waitFrame() command doing that in the loop?
Btw was unable to use the aviDemo command, add to use Fraps, the recordDemo worked but the aviDemo that makes the TGA images from the .demo just crashed, always, i'm using fhdoom.
I use stock D3, not fhdoom, so I'm not sure if avidemo/game works in there.
I think Motorsep got a working LOD system in his D3BFG engine, not 100% sure though.
What it looks like it's doing is it's removing the existing model & replacing it with another, with that slight pause. I'm guessing that is because the "setmodel" command changes the entitiys model, but takes a frame to process.
If a model with a nodraw material on it doesn't use any CPU resources, what might be a better idea is to have all the models actually be one model & change the model's skin from nodraw to what it should be. That might solve the issue.
Another could be to use a separate entity for each model & hide/show as needed.
QuoteAnother could be to use a separate entity for each model & hide/show as needed.
This doesn't work as well also causes flickering, it seams doomscript is just to slow for this. :-\
code
/***********************************************************************
lod_object_base.script
self script contains any LOD's specific code.
***********************************************************************/
#define LOD_LEVEL_0 1
#define LOD_LEVEL_1 2
#define LOD_LEVEL_2 3
object lod_object_base {
// bool to control the while loop
boolean isON;
// enable or disable the LOD check, no need to do it on objects with no lod's
float lod_enabled;
// lod0 position and rotation for the other lod's
vector currObjPos;
vector currObjRot;
// var to control the LOD_LEVEL_x static vars
float currentLOD;
entity lod1;
entity lod2;
string lod1_name;
string lod2_name;
// show distances
float lod1_dis;
float lod2_dis;
// player entity
entity lod_player;
// player distance from lod object
float pldistance;
void init();
void lodSetup();
void lod0_Show();
void lod0_Hide();
void lodUpdate();
void checkLOD();
};
void lod_object_base::lod0_Show(){
self.show();
}
void lod_object_base::lod0_Hide(){
self.hide();
}
void lod_object_base::lodSetup(){
// to be able to spawn a new object i need to get its name, from lod0 def file, as a string,
// for that i use the getkey() function
// then use sys.spawn to spawn the object using that string as a name.
lod1_name = self.getKey("def_LOD1");
lod1 = sys.spawn(lod1_name);
lod1.setWorldOrigin(currObjPos); // makes the lod1 obj have the same position as lod0
lod1.setAngles(currObjRot); // makes the lod1 obj have the same Rotation as lod0
lod1_dis = self.getIntKey("lod1_distance"); // gets from lod0 the lod1 spawnarg show distance
lod1.hide();
lod2_name = self.getKey("def_LOD2");
lod2 = sys.spawn(lod2_name);
lod2.setWorldOrigin(currObjPos);
lod2.setAngles(currObjRot);
lod2_dis = self.getIntKey("lod2_distance");
lod2.hide();
}
/*
============
lod_object_base::checkLOD
============
*/
void lod_object_base::checkLOD()
{
pldistance = self.distanceTo(lod_player); // check lod obj pos distance to player1 pos
if( pldistance < lod1_dis && currentLOD != LOD_LEVEL_0 ){
currentLOD = LOD_LEVEL_0;
lod0_Show();
lod1.hide();
lod2.hide();
}
else if ( pldistance >= lod1_dis && pldistance < lod2_dis && currentLOD != LOD_LEVEL_1 ){
currentLOD = LOD_LEVEL_1;
lod0_Hide();
lod1.show();
lod2.hide();
}
else if ( pldistance >= lod2_dis && currentLOD != LOD_LEVEL_2 ){
currentLOD = LOD_LEVEL_2;
lod2.show();
lod1.hide();
lod0_Hide();
}
}
/*
============
lod_object_base::lodUpdate
============
*/
void lod_object_base::lodUpdate() {
/////////////////////// LOD's setup
lod_enabled = self.getIntKey("lod"); // get the spawn lod value
// if spawnarg lod is 0 disable the while loop, saves performance
if(lod_enabled == 0){
isON = false;
}
// gets the lod0 world position and rotation
currObjPos = self.getWorldOrigin();
currObjRot = self.getAngles();
currentLOD = LOD_LEVEL_2;
// spawn the lod entities
lodSetup();
// this gets the player entity but is redundant, we could simple use $player1
lod_player = sys.getEntity("player1");
// runtime loop to check for the player position and spawn the lod objs
while ( isON ){ // while isON == true
checkLOD();
sys.waitFrame();
}
}
/*
===============
initialisation
================
*/
void lod_object_base::init()
{
sys.waitFrame();
isON = true;
thread lodUpdate();
}
no, it's not to slow. I've done similar things before via script. (the video attached).
I'm wondering now if it's a flaw in the custom D3 engine you're using.
Thanks for the help The Happy Friar but unfortunately this happens with vanilla Doom 3 has well, the video you posted shows very fast model change indeed but i'm unable to replicate here, perhaps it is because i'm also running a frob check (while loop with a traceline) every frame slowing everything down, need to test disabling the frob script.
Quote from: The Happy Friar on November 25, 2016, 05:16:03 PM
I think Motorsep got a working LOD system in his D3BFG engine, not 100% sure though.
We did. Can be easily ported into fhDoom I believe.
Quote from: argoon on November 28, 2016, 12:27:33 PM
Thanks for the help The Happy Friar but unfortunately this happens with vanilla Doom 3 has well, the video you posted shows very fast model change indeed but i'm unable to replicate here, perhaps it is because i'm also running a frob check (while loop with a traceline) every frame slowing everything down, need to test disabling the frob script.
Wouldn't need to do it every frame, maybe even have it check different distances at different frames. IE closes one every two frame, furthest every 10 frames?
Quote from: motorsep on November 28, 2016, 01:39:46 PM
Quote from: The Happy Friar on November 25, 2016, 05:16:03 PM
I think Motorsep got a working LOD system in his D3BFG engine, not 100% sure though.
We did. Can be easily ported into fhDoom I believe.
Or that. :)
Quote from: The Happy Friar on November 28, 2016, 09:23:44 PM
Quote from: argoon on November 28, 2016, 12:27:33 PM
Thanks for the help The Happy Friar but unfortunately this happens with vanilla Doom 3 has well, the video you posted shows very fast model change indeed but i'm unable to replicate here, perhaps it is because i'm also running a frob check (while loop with a traceline) every frame slowing everything down, need to test disabling the frob script.
Wouldn't need to do it every frame, maybe even have it check different distances at different frames. IE closes one every two frame, furthest every 10 frames?
Quote from: motorsep on November 28, 2016, 01:39:46 PM
Quote from: The Happy Friar on November 25, 2016, 05:16:03 PM
I think Motorsep got a working LOD system in his D3BFG engine, not 100% sure though.
We did. Can be easily ported into fhDoom I believe.
Or that. :)
Man this is frustrating i disabled the frob script and my lod system still flickers, and the fps's are above 60 proving that performance is not the problem, perhaps i'm doing something wrong? Is my script missing something? I'm i doing it wrong? Do i need to mess with threads? I don't really understand threads for now. Could it be because I'm running the mod from a external HDD? But i'm not really spawning anything at run time!? Could the waitframe() be causing the blank frame? Logically it sounds like it, because it makes the loop wait a frame, but when i remove it i get a engine crash with a loop error.
The Happy Friar thank you for your input, i don't really know at the moment how to do what you say but i will try.
About the Motorsep LOD system unfortunately, i don't think eXistence will port it to fhdoom anytime soon and i don't want to mess with the engine source for now, is beyond my coding capacities i'm having problems with doomScript imagine C++. ;D :P
Does your script work by itself it does it need specific assets? Could anyone test it out w/o extra content?
If you want to test then you don't need specific models just use this model def's with any model. :)
entityDef LOD_base{
"inherit" "func_static"
"scriptobject" "lod_object_base" // name of the lod script
"spawnclass" "idStaticEntity"
"editor_usage" "LOD enabled entity objects"
"editor_usage1" "def_LOD models most have model name with _lodx sufix"
"editor_var lod1_distance" "distance to show lod1 object"
"editor_var lod2_distance" "distance to show lod2 object"
"editor_bool lod" "set to 1 to enable lod for this entity."
"editor_var def_LOD1" "chose model def object to be lod1 object"
"editor_var def_LOD2" "chose model object def to be lod1 object"
"editor_var noShadows" "disable shadows used mostly for last lod"
"lod" "1" // enables or disables the LOD system
"lod1_distance" "300"
"lod2_distance" "600"
"noShadows" "0"
}
entityDef LOD_testObj {
"inherit" "LOD_base"
"editor_color" ".3 .3 1"
"editor_mins" "-16 -16 0"
"editor_maxs" "16 16 32"
"editor_usage" "LOD enabled test object - NOT USE"
"editor_var lod1_distance" "distance to show lod1 object"
"editor_var lod2_distance" "distance to show lod2 object"
"editor_var def_LOD1" "chose model def object to be lod1 object"
"editor_var def_LOD2" "chose model object def to be lod2 object"
"model" "lod0 model path"
"def_LOD1" "LOD_testObj_lod1"
"def_LOD2" "LOD_testObj_lod2"
"lod1_distance" "300"
"lod2_distance" "600"
}
entityDef LOD_testObj_lod1 {
"inherit" "func_static"
"editor_usage" "LOD enabled test object - NOT USE"
"model" "lod1 model path"
}
entityDef LOD_testObj_lod2 {
"inherit" "func_static"
"editor_usage" "LOD enabled test object - NOT USE"
"model" "lod2 model path"
"noShadows" "1"
}
Even tho i already changed the script somewhat you can still use the last script i posted or the first with the setmodel system all display the same behavior on my PC.
So what kind of FPS boost do you get from this?
Hello VGames on simple scenes or interior scenes where portals are very effective you don't get that much of a gain if any, the model change also takes performance, this is for outdoor scenes with a big number of models, like forests (for what i'm really trying to do this LOD system), open spaces and stuff, levels where portals are very inefficient and hard to optimize, for anyone making Doom 3 kind of levels LOD is really not necessary that is why id never implemented it.
I'm also making it because i want to see if i can.
Oh ok. I hope you can get it working properly. I'd love to see bigger opened up maps. Especially a forest. Good luck.
Quote from: VGames on December 02, 2016, 08:14:33 AM
I'd love to see bigger opened up maps. Especially a forest. Good luck.
Except you can't. LOD only remedies polycount, but not drawcalls. Engine would need dynamic/static batching and instancing, on both meshes and materials. And it needs to be multithreaded, plug some of it needs to be offloaded to GPU. And top of that you need occlusion culling.
Quote from: motorsep on December 02, 2016, 02:10:51 PM
Quote from: VGames on December 02, 2016, 08:14:33 AM
I'd love to see bigger opened up maps. Especially a forest. Good luck.
Except you can't. LOD only remedies polycount, but not drawcalls. Engine would need dynamic/static batching and instancing, on both meshes and materials. And it needs to be multithreaded, plug some of it needs to be offloaded to GPU. And top of that you need occlusion culling.
Even for a small forest?
Quote from: motorsep on December 02, 2016, 02:10:51 PM
Quote from: VGames on December 02, 2016, 08:14:33 AM
I'd love to see bigger opened up maps. Especially a forest. Good luck.
Except you can't. LOD only remedies polycount, but not drawcalls. Engine would need dynamic/static batching and instancing, on both meshes and materials. And it needs to be multithreaded, plug some of it needs to be offloaded to GPU. And top of that you need occlusion culling.
You are right it doesn't resolve the drawcall problem but i assume it helps reduce their complexity, specially on the perpixel lighting system of idtech 4 plus you have the option to disable shadow casting and physics calculation in the distance.
Yes dynamic/static batching and instancing / impostors would be awesome to have, but we don't so we need to play with what we have.
Automatic Occlusion culling like Umbra would be nice to have but we don't, so again use what we have, i'm thinking of ways to also script a pseudo Occlusion Culling system by using the bounding box size and traces, is not perfect far from it but i think it would work.
About forest size, of course this will not make us able to do Crysis like forests but at lest will help us make bigger ones compared to no LOD at all.
A update on this, i found that i add hide all the objects at init() time including lod0, so it worked better BUT i'm still not able to make the LOD system not flicker but now i'm pretty sure it is caused by the waitFrame(); or wait(); command on the while loop, why i think this, because by using wait(some number of time) with a very low number i was able to accelerate the change, at lest it felt like it, but still not to the point of no flicker, a number below a certain range would also stop the lod system from working.
In other news i was able to make a grass LOD system using this that performs well, unfortunately it also suffers from this blank frame problem but is not so obvious as i'm changing to relatively different models.
Here is a video, sorry about the resolution, google drive compresses even more the video, some things to note, the level is just a test level, I just took a doom 3 model with some open space and used that, the grass model and material is just a test so it looks funky and out of place i know, i could color the material very easily using a grayscale diffuse and a color stage but that is for another time.
About performance FRAPS took half the performance, normally it would run at constant 60+fps and this on a AMD GPU that idtech4 is not very friendly to. :)
https://drive.google.com/open?id=0B_xD8k_3dkNpcXlaM2ZhY1NqTEU (https://drive.google.com/open?id=0B_xD8k_3dkNpcXlaM2ZhY1NqTEU)
I want to make this even better by not having to spawn all objects at init() time so i don't have hundreds of grass objects "thinking" at the same time even if hidden and way from the player, and i hope that some day i can resolve the blank frame problem.
BTW is it possible to detect by script the size of a model on screenspace? I mean detect how large an object is relative to the game resolution? If it takes 25% of screen, 50%, etc, i hope i'm making my self clear, i found this is how UE4 does its auto LOD system.
Don't you have YouTube channel to upload videos? :-\
Quote from: motorsep on December 06, 2016, 04:55:17 PM
Don't you have YouTube channel to upload videos? :-\
Was faster to upload to google drive, here is youtube version still not perfect it seams, i need to mess with fraps settings and see if i can make better videos the video comes very dark forcing me to edit it with virtual dub.
Even tho the frame ingame shows bellow 30fps the speed on youtube is right the grass LOD does runs at 60fps, it was just fraps making the game run slow but it recorded it at 60fps like it should.
When I am at work, I can't watch non-youtube videos (either way it's just inconvenient).
Nice. I'd suggest making it darker where it meets the floor, kinda in a gradient fashing - darker at the bottom, lighter on top. Can even do that using vertex color so texture remains intact. Also might want to add a quad at the "root" (so it's right on the ground), with offset in the material and make a cloudy dark blob modulated texture - it will be fake AO.
What happens when you make a really dense grass? (if you have floor texture grassy, just like actual grass, it will look even better)
Do you use alpha test opacity on the grass ?
Quote from: motorsep on December 06, 2016, 09:15:23 PM
When I am at work, I can't watch non-youtube videos (either way it's just inconvenient).
Nice. I'd suggest making it darker where it meets the floor, kinda in a gradient fashing - darker at the bottom, lighter on top. Can even do that using vertex color so texture remains intact. Also might want to add a quad at the "root" (so it's right on the ground), with offset in the material and make a cloudy dark blob modulated texture - it will be fake AO.
What happens when you make a really dense grass? (if you have floor texture grassy, just like actual grass, it will look even better)
Do you use alpha test opacity on the grass ?
Thanks for the suggestions, they indeed would make this grass look better, about dense grass i'm still to test that, but like you say, the lack of density will be masked when the grass is used with a more suitable floor texture, about alpha, i use both alpha test and alpha blending by using the keyword translucent in the material, i have a material version with normal maps and capable of interacting with light but for the time it takes to much performance, compared to this version, this one is brighter but i can tweak that very easily.
You shouldn't be using alpha blending as it's the most performance taxing solution. Alpha test with antialiasing should yield better performing grass than alpha blending.
Also, to reduce overdraw and fillrate, instead of having quad with grass texture on it, cut the mesh around the grass texture, to make mesh shape resemble outer contour of the grass (and still keep polycount to minimum of course). Drawing more triangles isn't an issue with modern GPUs. The problem is that while all those transparent pixels are not visible, they still render.
this thing is much better resolved in the rendering side of the engine, and as Motorsep pointed out this might need other tech in the engine than just simply replacing models.
I know this would be better in the engine side but i just don't want to mess with it for now, i'm still learning to code.
Motorsep i did what you said about
Quote...cut the mesh around the grass texture...
and even tho i know that is generally true, it seams in this case it didn't worked as expect, first i didn't got any performance bump of note (i have still to do that to the lod0 tho) and second it caused the "deform sprite" material keyword to crash the engine, i need that to make the far away plane look always at the player. I tried to code my own "lookAt" code and even tho it worked it made everything too slow.
About your vertexcolors suggestion, worked like a charm but i also found out that if i use "deform sprite" in a material i can't use vertex colors at the same time it seams, causes the material to go black.
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.
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.
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 (https://drive.google.com/drive/folders/0B_xD8k_3dkNpNjNoam9TMVo2Sm8?usp=sharing), 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 (https://drive.google.com/drive/folders/0B_xD8k_3dkNpZjJZR0xpdWJZYzA?usp=sharing), but unfortunately it doesn't seam to work and i don't know why.
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.
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.
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.
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.
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?
haven't had time to test, I was basing it on my previous experiments with loading random entities.
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?
While idTech 4 doesn't have it, Storm Engine 2 does ;) Check source on github
q3a did? I don't remember it in the stock game.
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.
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;
}
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...
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?
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.
So you think it's just for performance when the poly difference can't be seen?
@ 1920x1080 I couldn't tell a difference between up close & getting farther. In the first two Serious Sam games, the LOD doesn't change when zoomed in, it's based on your distance only. Q3A's a 99/00 game, it would be pretty advanced to take in to account your zoom with the LOD system.
(http://www.violae.net/temp/q3alod_pm.gif)
(http://www.violae.net/temp/q3alod_map.gif)
The LOD working in FOV - it's more like when you see the world as real in rear sight and as Minecraft in telescopic sight :)
I couldn't get it to change for me. what's the cvar for showing tris? I forget.
r_showtris 1/2
P.S. About LOD in AVP2:
http://fallout.bplaced.net/dedit/tutorials/dedit_docs_avp2/ModelEdit.htm
You need to load maps using "devmap", you may also need to set "sv_pure 0".
Huh
AutoLOD in 2001.
i got a video of the q3a lod in action.
https://www.youtube.com/watch?v=VSqoKmvVCdg&feature=youtu.be
how it figures out when to enable lod seems kinda weird. in my video you can see at a one distance it will bounce between the high detail & mid detail model, however, when it's facing me, it goes mid poly, away = high poly. Like it's based on a trace from you to the closes bounding box point, not origin.
also, no matter what res i tried, unless showtris was on, i couldn't tell it was lower poly, like it determines how many polys it shows based on distance and/or resolution, so it's not noticeable.
I've been playing the game since it came out & never even knew it had it until this thread.