Model Lod
by Guimo · in Torque Game Engine Advanced · 08/13/2007 (2:40 pm) · 13 replies
TGEA 1.0.2 has a problem with meshes LOD. Looks like its selecting one lower LOD than required so at mid distance, where the mid poly shape should show, the lower poly version shows. On close range (about 2 units away) the medium poly version shows and in really close range (say just an instant before I get the item) then the highest version shows.
This test was done using the standar Crossbow Ammo Clip, but happens with every object in my game including vehicles and players.
I would like to send and image but I dont know how to attach it to this post.
Luck!
Guimo
This test was done using the standar Crossbow Ammo Clip, but happens with every object in my game including vehicles and players.
I would like to send and image but I dont know how to attach it to this post.
Luck!
Guimo
About the author
#2
08/19/2007 (8:20 am)
I'm having this issue as well, haven't found a fix for it yet. On models which only have one LOD they often won't display at all until you get very close to them. I hard coded it at the moment to render them unless they are under a certain number of pixels, but that's a terrible hack, and I couldn't figure out a better solution. 
#4
08/21/2007 (1:05 pm)
Not really but I'm not sure if it really an error or just the pixelsize has been redefined to something different than it was in TGE
#5
You could be right! I've been through every model in our game since porting to TGEA to re-adjust the LODding numbers to LOD at the corect distance etc. as they were Lodding too far out .. Hope I haven't got to go through them again to put them all back, nighmare!,,... ha ha, aaah, I love doing things 3 times 8)
08/21/2007 (1:15 pm)
LOL !!You could be right! I've been through every model in our game since porting to TGEA to re-adjust the LODding numbers to LOD at the corect distance etc. as they were Lodding too far out .. Hope I haven't got to go through them again to put them all back, nighmare!,,... ha ha, aaah, I love doing things 3 times 8)
#6
08/22/2007 (12:05 am)
It appears to me that if your model has like one stock LOD and it is set at 64 pixels for example, then the model will not draw at all unless it is 64 pixels. If your lowest level of detail is set at 2 pixels then your okay. If it's larger you'll either need to recompile the dts shape or if that is not an option you can hard code it to display it anyway so long as it is above a certain number of pixels.
#7
at 10cm distance, its on full detail, a step away its on minimum and it is clearly more than 2 units in size at which level this detail should be shown (the other are 64 and 200)
Or are the 2 units measured in 320x240 resolution? (when running on 1680x1050)
I tested it in Torque Showtool Pro and it is nearly impossible to get it to detail 2 here (somewhere around 148 units away)
EDIT: the one with the 320x240 should have been a joke ...
08/22/2007 (2:48 am)
But that does not explain why for example the ammo of the fps.starter is that broken.at 10cm distance, its on full detail, a step away its on minimum and it is clearly more than 2 units in size at which level this detail should be shown (the other are 64 and 200)
Or are the 2 units measured in 320x240 resolution? (when running on 1680x1050)
I tested it in Torque Showtool Pro and it is nearly impossible to get it to detail 2 here (somewhere around 148 units away)
EDIT: the one with the 320x240 should have been a joke ...
#8
08/22/2007 (8:14 am)
Your suggestion about TGEA measuring the units in low resolution (320x240) even when the resolution has changed would explain the problem. Does anybody knows where in the engine I may locate the code for this size test? 
#10
@Guimo - The location you are looking for I believe is TSShapeInstance::selectCurrentDetail() in tsShapeInstance.cpp Your lines of interest are:
Does anyone know what the '1.6f' is in there for?
09/18/2007 (8:02 am)
Marc is right. There seems to be a set assumed resolution in 1.0.3 for checking lod. and I don't think I'm the first to see it since 'bjg' commented about it in the code :)Quote:// CodeReview Following block seems to have some aspect ratio/view sizeI don't think they were double checked :)
// assumptions; we should double check them. [bjg, 5/14/07]
@Guimo - The location you are looking for I believe is TSShapeInstance::selectCurrentDetail() in tsShapeInstance.cpp Your lines of interest are:
Quote:RectI viewport = state->getBaseZoneState().viewport;
F32 pixelScale = viewport.extent.x * 1.6f / 640.0f;
F32 pixelRadius = state->calculateProjectedRadius(dist,mShape->radius) * pixelScale * smDetailAdjust;
Does anyone know what the '1.6f' is in there for?
#11
There has to be a better solution to make everyone happy, but for those who are developing in a 4:3 res just take out the '* 1.6' for now, until someone posts the solution. I could be wrong but that seems like the problem that ppl are talking about.
09/18/2007 (8:17 am)
Ok, so the horizontal scale of 1.6 is for 16:10 aspect ratios.There has to be a better solution to make everyone happy, but for those who are developing in a 4:3 res just take out the '* 1.6' for now, until someone posts the solution. I could be wrong but that seems like the problem that ppl are talking about.
#12
The problem is that the whole value is a 6-10 times to small (thats at least what the raise of DetailAdjust to 6+ in the prefs indicates) so one of the things there is massively wrong.
Don't know if the original input is already bogus or if its the calculateProjectedRadius (I still think its highly strange that you project the radius against a dist, but above the dist is divided by the scale ... that looks like double down scaling it. But this on its own isn't the issue as the dist modification does not make any difference to the end result)
still having a look on this, but as spare time programmer, I don't have that much time which is why it takes some time to find the real root of the problem.
09/19/2007 (12:19 am)
Not really, I am on a 16:10 (1680x1050).The problem is that the whole value is a 6-10 times to small (thats at least what the raise of DetailAdjust to 6+ in the prefs indicates) so one of the things there is massively wrong.
Don't know if the original input is already bogus or if its the calculateProjectedRadius (I still think its highly strange that you project the radius against a dist, but above the dist is divided by the scale ... that looks like double down scaling it. But this on its own isn't the issue as the dist modification does not make any difference to the end result)
still having a look on this, but as spare time programmer, I don't have that much time which is why it takes some time to find the real root of the problem.
#13
I don't have time to pick apart all of the individual changes but you can find the affected files here:
www.rustycode.com/matt/LOD_Fix.zip
I merged it into a version of TGEA that is pretty close to 1.0.3 and it appears to be working with Andy's scout ship model.
Lemme know if it doesn't work =)
01/15/2008 (4:07 pm)
Hey guys,I don't have time to pick apart all of the individual changes but you can find the affected files here:
www.rustycode.com/matt/LOD_Fix.zip
I merged it into a version of TGEA that is pretty close to 1.0.3 and it appears to be working with Andy's scout ship model.
Lemme know if it doesn't work =)
Torque 3D Owner Marc Dreamora Schaerer
Gayasoft
We have this issue as well although I'm not sure if this is bound to TGE models that have this issue as our newly created trees don't see to behave like that. we are still testing the issue at the moment as we just started to check our game against the 1.0.2 fixes.