DTS Objects (some stock) won't calc pixelsize for LOD - RESOLVED
by Henry Todd · in Torque 3D Professional · 01/12/2010 (8:54 am) · 32 replies
I discovered this while trying to test some simple 1st/3rd person code I was hacking together. It would seem that the 3ds DTS exporter is incapable of producing a DTS that can LOD at all. Every DTS model I've made using 3ds 2009's exporter absolutely refuses to identify pixel values in the shape editor, and likewise refuses to LOD properly. This seems to be a rather severe issue with the LOD system.
In fact, the swarmGun model that comes with the game also doesn't like to return pixel values -- go ahead and load it up in the shape editor and zoom in/out, you'll see what I mean. The debris model? Yes. Rocket? No. Something is definitely screwy in pixel size calculation. I can't find any common ground between the objects that do handle pixel size calculations and the ones that don't, very confusing.
When it doesn't get a pixel size value, it seems to just stick in ... whatever. Many models use LOD 2 when they don't intend to have more than 1 LOD, so generally all of these models are rendering correctly in-game -- until you try one that actually has LOD states, confirming that it's not just the shape editor reporting an incorrect value.
I'm not sure if it's the exporter or the engine, but either way it needs a fix. That max2dts exporter is what a good % of us are using. The confusing bit is that the detail levels are being picked up correctly, I can scroll through them in the editor with the detail level editing box, but the pixel size doesn't change when zooming in/out.
Other random example: forgeSoldier doesn't return pixelsize values, but the elf does. Both DTS, both seem to be identically rigged.
**edit: My simple test object does return pixelSize values in the shape editor when exported as DAE. That's a definite workaround, but not a solution by any means. This is definitely an issue with DTS files.
In fact, the swarmGun model that comes with the game also doesn't like to return pixel values -- go ahead and load it up in the shape editor and zoom in/out, you'll see what I mean. The debris model? Yes. Rocket? No. Something is definitely screwy in pixel size calculation. I can't find any common ground between the objects that do handle pixel size calculations and the ones that don't, very confusing.
When it doesn't get a pixel size value, it seems to just stick in ... whatever. Many models use LOD 2 when they don't intend to have more than 1 LOD, so generally all of these models are rendering correctly in-game -- until you try one that actually has LOD states, confirming that it's not just the shape editor reporting an incorrect value.
I'm not sure if it's the exporter or the engine, but either way it needs a fix. That max2dts exporter is what a good % of us are using. The confusing bit is that the detail levels are being picked up correctly, I can scroll through them in the editor with the detail level editing box, but the pixel size doesn't change when zooming in/out.
Other random example: forgeSoldier doesn't return pixelsize values, but the elf does. Both DTS, both seem to be identically rigged.
**edit: My simple test object does return pixelSize values in the shape editor when exported as DAE. That's a definite workaround, but not a solution by any means. This is definitely an issue with DTS files.
About the author
Recent Threads
#2
Additionally, at least 1 or the objects I mentioned has no LOD yet still correctly generates a pixel size in the editor. Specifically try the SpaceOrc, it returns pixel size values and has only 1 LOD, while the ForgeSoldier, also only 1 LOD, does not.
These two models are identically rigged, leading me to believe they were exported with different max2dts exporters, or one was actually dumped to DAE originally, otherwise the problem is somehow in the geometry (but doesn't the engine use the bounding box size for determining pixel size?).
Probably also worth mentioning that I'm referring to the "pixel" value on the editor's LOD edit box. I'm calling it pixelSize because that's the name consistantly used for the vars that represent this value in the code. :P
With this in mind -- the idea that shapes without detail levels shouldn't bother to calc pixel size -- could that suggest the system that makes this determination is broken?
01/12/2010 (3:07 pm)
The question, then, is why an object I just exported with 3 LODs won't return a pixel size. The shape editor shows the 3 levels correctly, but won't generate a pixel size value as I zoom in and out, instead simply showing the last value of the previous loaded model (or 0 if it's the first model loaded).Additionally, at least 1 or the objects I mentioned has no LOD yet still correctly generates a pixel size in the editor. Specifically try the SpaceOrc, it returns pixel size values and has only 1 LOD, while the ForgeSoldier, also only 1 LOD, does not.
These two models are identically rigged, leading me to believe they were exported with different max2dts exporters, or one was actually dumped to DAE originally, otherwise the problem is somehow in the geometry (but doesn't the engine use the bounding box size for determining pixel size?).
Probably also worth mentioning that I'm referring to the "pixel" value on the editor's LOD edit box. I'm calling it pixelSize because that's the name consistantly used for the vars that represent this value in the code. :P
With this in mind -- the idea that shapes without detail levels shouldn't bother to calc pixel size -- could that suggest the system that makes this determination is broken?
#3
New models should set maxError to -1 (this is the responsibility of the DTS exporter).
My guess is that the max DTS exporter is doing the wrong thing here. If they want to use 'screen error' for LOD, then they need to set the fields up correctly (not just leave them uninitialised). More likely, they should just set them to -1 so pixel size LOD is used instead.
01/12/2010 (5:00 pm)
The models that don't update pixelSize in the shape editor appear to have the 'maxError' field of their detail levels set to some uninitialised value (eg. 1.2518478e-009). Comments in the relevant engine code indicate that this field was used by an old way of doing LOD (using a 'screen error' metric instead of pixel size) that has been retained for legacy models.New models should set maxError to -1 (this is the responsibility of the DTS exporter).
My guess is that the max DTS exporter is doing the wrong thing here. If they want to use 'screen error' for LOD, then they need to set the fields up correctly (not just leave them uninitialised). More likely, they should just set them to -1 so pixel size LOD is used instead.
#4
01/12/2010 (5:08 pm)
I'm not sure how easy it is to get the DTS exporter updated => but you could easily fix this when the DTS shapes are loaded by setting detail level fields manually. eg. in TSShape::assembleShape in tsShape.cpp (about line 1047):}
// Force use of pixel-size method for LOD
for (S32 i = 0; i < details.size(); i++)
{
details[i].maxError = -1;
details[i].averageError = -1;
}
tsalloc.checkGuard();
// about to read in the meshes...first must allocate some scratch space
#5
Getting the DTS exporter updated seems to be an issue.. even the version I found for max 2009 was actually updated by the community, not GG. If I can manage to find the source somewhere, I'll see if I can update it, but Max script is mostly foreign to me.
Perhaps a workaround on GG's part could be a method for setting these screenerror values in the shape editor. Or I just need to get with the times and use collada + DSQ's.
01/12/2010 (6:00 pm)
Ah, so it is the exporter, nice catch. Thanks for the workaround, I can't see any way this would break anything I'm doing, so I'll be using it until there's a better fix. I'm not personally ready to move to Collada, simply because I invested so much time in understanding the DTS export processes (also not sure that it handles animation yet). :PGetting the DTS exporter updated seems to be an issue.. even the version I found for max 2009 was actually updated by the community, not GG. If I can manage to find the source somewhere, I'll see if I can update it, but Max script is mostly foreign to me.
Perhaps a workaround on GG's part could be a method for setting these screenerror values in the shape editor. Or I just need to get with the times and use collada + DSQ's.
#6
While I agree it may be useful for the Shape Editor to show the screenerror values for legacy shapes, this would not help with the problem of LOD not working for models exported with uninitialised values.
T3D is happy to fall-back to the screenerror method (which should work both in-game and in the shape editor, even though the pixel size value does not update). The real issue is that these models contain garbage values so LOD does not work as it should (even in legacy mode).
01/12/2010 (6:28 pm)
Quote:Perhaps a workaround on GG's part could be a method for setting these screenerror values in the shape editor.
While I agree it may be useful for the Shape Editor to show the screenerror values for legacy shapes, this would not help with the problem of LOD not working for models exported with uninitialised values.
T3D is happy to fall-back to the screenerror method (which should work both in-game and in the shape editor, even though the pixel size value does not update). The real issue is that these models contain garbage values so LOD does not work as it should (even in legacy mode).
#7
01/12/2010 (6:38 pm)
I meant, considering how much of the model's setup can be changed from script/editor at this point, it makes sense that it could also allow you to manually set the screenerror values to -1 (or an actual value if you wanted) for each detail level in order to correct this. Honestly sounds like more effort than it's worth now that I write it out. 
#8
I'm using Max 9 GarageGames websitesite expoerter and am suffering from this with most of the models I make.
04/04/2010 (6:22 am)
Is there no workaround fix, like unmessDts that can be run on the DTS's?I'm using Max 9 GarageGames websitesite expoerter and am suffering from this with most of the models I make.
#9
1. Make the source code change listed above to fixup the uninitialised value when the DTS file is loaded.
2. Use a hex editor to patch the DTS file manually. Possible but tedious and tricky to get right.
04/06/2010 (2:52 pm)
David: There are 2 workarounds available:1. Make the source code change listed above to fixup the uninitialised value when the DTS file is loaded.
2. Use a hex editor to patch the DTS file manually. Possible but tedious and tricky to get right.
#10
well source code works for me, but what about all the other people that use my DTS's? I can't realy sell a DTS and say sorry because of an error in GarageGames exporter the LOD's may not work without you editing your engine, dosn't make me or you GarageGames look good :-(
The hex editor is a possibility if I knew what to edit, I could even write a program to edit the DTS's If I had any Idea what it was I was suposed to be changing.
Isn't there a way of manualy setting the maxError to -1 in Max? or is there anyone out there who would recompile the Max 9 exporter to set the values or is there another version of Max I can import my meshes into then re export them? I don't want to use another program to create my models as I'm quite used to Max
04/06/2010 (3:42 pm)
Hi Chriswell source code works for me, but what about all the other people that use my DTS's? I can't realy sell a DTS and say sorry because of an error in GarageGames exporter the LOD's may not work without you editing your engine, dosn't make me or you GarageGames look good :-(
The hex editor is a possibility if I knew what to edit, I could even write a program to edit the DTS's If I had any Idea what it was I was suposed to be changing.
Isn't there a way of manualy setting the maxError to -1 in Max? or is there anyone out there who would recompile the Max 9 exporter to set the values or is there another version of Max I can import my meshes into then re export them? I don't want to use another program to create my models as I'm quite used to Max
#11
The DTS format is not trivial to read/write, so if you wanted to create a program to make the changes for you automatically, I'd recommend starting with the T3D source anyway.
Obviously neither option is ideal; best plan is to get the Max exporter fixed. I'm not sure who to contact about that => wasn't the source code for this exporter shipped with earlier versions of Torque?
I'm not aware of any way to set maxError in Max.
04/06/2010 (4:51 pm)
If you make the source code change in T3D, you could then re-save the DTS files with the maxError and averageError values set correctly.The DTS format is not trivial to read/write, so if you wanted to create a program to make the changes for you automatically, I'd recommend starting with the T3D source anyway.
Obviously neither option is ideal; best plan is to get the Max exporter fixed. I'm not sure who to contact about that => wasn't the source code for this exporter shipped with earlier versions of Torque?
I'm not aware of any way to set maxError in Max.
#12
Delete xx.dts, Export as Collada, import the collada shape into T3D, rename the xx.cached.dts as xx.dts load the .dts as normal, fiddle with the materials to match your original .dts and you now have a .dts with working LOD's in T3D
D R Pemberton
www.deadlyassets.com
04/26/2010 (3:57 pm)
ok found a workaround.Delete xx.dts, Export as Collada, import the collada shape into T3D, rename the xx.cached.dts as xx.dts load the .dts as normal, fiddle with the materials to match your original .dts and you now have a .dts with working LOD's in T3D
D R Pemberton
www.deadlyassets.com
#13
- fixing the exporters for max is a partial fix.
- altering source is a partial fix.
This post summed up: If DTS worked for all of these years, why is it failing now and only in T3D ?
Don't blame the exporter for T3D's bug/incapability.
When will the engine get a 'final fix' for this ?
- There should be more explanation on this from someone at GG. Waiting until someone finds a major bug and then handing the issue off with a partial-fix by source change and suggesting exporters are recompiled is just poor IMO.
*Again, if DTS worked all of these years in half of a dozen engines, why does it fail in T3D ?
- I could recompile the Max exporters for 9,2009 and 2010/2011..in x86 flavor. YET, *I don't think that having me recompile exporters is a REAL solution. Nor do I like spending my time and energy fixing something for free that I feel is not the real issue.
Can you tell I am flustered ?
04/26/2010 (4:52 pm)
This is quite lame. .Seriously.- fixing the exporters for max is a partial fix.
- altering source is a partial fix.
This post summed up: If DTS worked for all of these years, why is it failing now and only in T3D ?
Don't blame the exporter for T3D's bug/incapability.
When will the engine get a 'final fix' for this ?
- There should be more explanation on this from someone at GG. Waiting until someone finds a major bug and then handing the issue off with a partial-fix by source change and suggesting exporters are recompiled is just poor IMO.
*Again, if DTS worked all of these years in half of a dozen engines, why does it fail in T3D ?
- I could recompile the Max exporters for 9,2009 and 2010/2011..in x86 flavor. YET, *I don't think that having me recompile exporters is a REAL solution. Nor do I like spending my time and energy fixing something for free that I feel is not the real issue.
Can you tell I am flustered ?
#14
04/26/2010 (5:43 pm)
@ed *agree*
#15
Two workarounds have been provided (one to the source, one to the workflow) but the ultimate resolution of this issue belongs with the owner/maintainer of the MAX exporter.
Incidentally, which MAX exporter is this? Does anyone know if it is still based on the DTSSDK? (since any exporter based on that SDK will not suffer from this issue; the SDK initialises maxError and averageError to the proper -1 value).
Also, can someone confirm that LOD for a DTS shape from this exporter does work in TGE or TGEA? Most of the LOD selection code remains unchanged in T3D, so it seems strange that shapes with bad maxError values would work in previous versions of Torque but not T3D.
04/28/2010 (7:47 pm)
Just to be clear => the bug is in the MAX exporter. Nothing is broken in DTS or T3D. These buggy DTS files may have worked (possibly by accident) with previous versions of Torque, but I completely disagree that T3D should continue to work around or otherwise mask what is ultimately an exporter error.Two workarounds have been provided (one to the source, one to the workflow) but the ultimate resolution of this issue belongs with the owner/maintainer of the MAX exporter.
Incidentally, which MAX exporter is this? Does anyone know if it is still based on the DTSSDK? (since any exporter based on that SDK will not suffer from this issue; the SDK initialises maxError and averageError to the proper -1 value).
Also, can someone confirm that LOD for a DTS shape from this exporter does work in TGE or TGEA? Most of the LOD selection code remains unchanged in T3D, so it seems strange that shapes with bad maxError values would work in previous versions of Torque but not T3D.
#16
DR Pemberton also said in an email to me that he tried my max 2010 exporter and the same issue occurred. **I compiled my exporters with the DTSSDK.
That's all I have to add for tonight...I may have more to add after I get some zzz's.
04/28/2010 (10:16 pm)
DR Pemberton said: "I'm using Max 9 GarageGames websitesite expoerter and am suffering from this with most of the models I make."DR Pemberton also said in an email to me that he tried my max 2010 exporter and the same issue occurred. **I compiled my exporters with the DTSSDK.
That's all I have to add for tonight...I may have more to add after I get some zzz's.
#17
but show the same LOD error in ShowTool Pro.
You can use the LOD slider to see all the LOD's but when you scroll the object away its LOD's do not display correctly, exactly the same error as in T3D..
I'm working on a FREE asset at the min so don't mind sharing the .dts I'm having the problem with:-
www.deadlyassets.com/FREE/FREE_50AE.zip
It's an Ammo Box for the Complete Desert Eagle asset pack
Am I the only 3D Studio Max user suffering from these Errors?
(edit)
oops I forgot that zip has the fixed shape,
just unzip the above files, into your /art/shapes/FREE_50AE folder, then drop this .dts shape in:-
www.deadlyassets.com/FREE/bugged_shells.dts
(/edit)
04/29/2010 (1:34 am)
The models work fine in unmodified TGEA 1.8.1but show the same LOD error in ShowTool Pro.
You can use the LOD slider to see all the LOD's but when you scroll the object away its LOD's do not display correctly, exactly the same error as in T3D..
I'm working on a FREE asset at the min so don't mind sharing the .dts I'm having the problem with:-
www.deadlyassets.com/FREE/FREE_50AE.zip
It's an Ammo Box for the Complete Desert Eagle asset pack
Am I the only 3D Studio Max user suffering from these Errors?
(edit)
oops I forgot that zip has the fixed shape,
just unzip the above files, into your /art/shapes/FREE_50AE folder, then drop this .dts shape in:-
www.deadlyassets.com/FREE/bugged_shells.dts
(/edit)
#18
edit: ok got the other file now.
04/29/2010 (9:09 pm)
Are you sure that's the right model? It only has a single detail level, and is DTS v26 (which means it was saved by T3D, not any exporter I am aware of).edit: ok got the other file now.
#19
I suspect the MAX exporter is writing these values as 0 for all detail levels in the shape => no wonder T3D is getting confused. It would be like setting the pixel-size of all details to the same value: never going to work.
I'm not sure why it worked in TGEA (I don't have the source for that handy), but ShowToolPro was based on TGE, so it probably doesn't work in TGE either. There are 2 options:
1. Have T3D workaround the MAX exporter bug by forcing use of the new pixel-size LOD method. This is essentially what the source code change suggested above does. No doubt someone will have an old DTS file (using the screen-error method) that will no longer work.
2. Fix the bug in the MAX exporter; it should set both maxError and averageError for all detail levels to -1. I don't know who maintains this tool.
04/29/2010 (9:31 pm)
Unlike the swarmgun, which has garbage values in the maxError/averageError fields, bugged_shell.dts has both values set to 0. This still tells Torque that you want to use the old screen-error method of LOD rather than the new (around since at least TGE 1.5.1) pixel-size method.I suspect the MAX exporter is writing these values as 0 for all detail levels in the shape => no wonder T3D is getting confused. It would be like setting the pixel-size of all details to the same value: never going to work.
I'm not sure why it worked in TGEA (I don't have the source for that handy), but ShowToolPro was based on TGE, so it probably doesn't work in TGE either. There are 2 options:
1. Have T3D workaround the MAX exporter bug by forcing use of the new pixel-size LOD method. This is essentially what the source code change suggested above does. No doubt someone will have an old DTS file (using the screen-error method) that will no longer work.
2. Fix the bug in the MAX exporter; it should set both maxError and averageError for all detail levels to -1. I don't know who maintains this tool.
#20
Chris, how can I check the "maxError/averageError" fields in a DTS model ?
I'd like to sort this out and recompile a few of the Max exporters.
04/29/2010 (9:50 pm)
The DTS exporters have not been supported by GG in years (as I assume you know)..They have been community supported for over 3 or 4 years now.Chris, how can I check the "maxError/averageError" fields in a DTS model ?
I'd like to sort this out and recompile a few of the Max exporters.
Associate Steve Acaster
[YorkshireRifles.com]
Size is just the detail#. I can't comment on Maya.
[edit] I thik therefore I am ... doh!