I am attempting to import a basic shape into TGEA. The object is the $HFS/houdini/help/examples/nodes/out/torque/TorqueDetailMap.otl from the Houdini Torque Help file sample.

- This object renders without problems or error (checked the dump.html)
- I am able to view the shape in Torque Show Tool Pro
- I place the .dts object along with the support files to C:\Torque\TGEA_1_8_0\Projects\Game Name\game\scriptsAndAssets\data\shapes\weapons\here
- In the Torque World Editor Creator i navigate to the location i placed the dts object and click.
- A ‘FATAL’ menu box appears with this message “Bad object box!”. I can click the Retry button or the Cancel button.
- I click the Retry button and get this message: “Torque has encountered an assertion with message Bad object box! Would you like to use the debugger? If you cancel, you won't be asked again until you restart Torque.
- I press the OK button
- My game exe dies. Vista pops up a menu stating ”GameName_DEBUG.exe has stopped working.“
- In the console.txt file, the last line has this message ”Tried to get the object for item 42, which is not InspectorData!"

These steps are repeatable with other .dts objects i attempt to import from Houdini.

I have hammered on this a bit without any luck. Any ideas? Thanks! (I have also posted this at the Torque forums.))

Ron Lindsey

My System
1. Vista Home Premium - Quad Core - 64bit - 4gig - Nvida 8800GT 750meg
2. Torque Engine Game Advance 1.8
3. Houdini 9.5.326

What actual example file is producing this result?

Without delving too deeply, if you can view it in ShowToolPro…the ‘DTS’ shape is probably ‘fine’….as the ShowToolPro is the engine, albeit an earlier build…but the DTS format has not changed with TGEA, the ‘render’ pipeline has…and I ‘think’ this is where the ‘issue’ lies, not with the ROP or DTS file.

Did you setup a proper DTSmaterial? for your primitives. The TGEA render pipeline may not have liked the node you made your material in…just tossing out some first thoughts.

$HFS/houdini/help/examples/nodes/out/torque/TorqueDetailMap.otl from the Houdini Torque Help file sample.

I used the example from the above Houdini Sample File without modifications. The DTS_Material node is present.

I have posted this same message over at the GarageGames forums site and support. I'll add more when I hear back.

Ron

Here is the on going conversation at the GarageGames forums:

http://www.garagegames.com/mg/forums/result.thread.php?qt=81978 [garagegames.com]

Ah….a ‘clue’…the ‘Detailmap’ shape…which would be some extra material goofiness, me tinks.

This sounds more and more like a ‘material’/Render issue with this build, and detail mapping, which I am not sure was ever ‘supported’ in the engine, while the DTS format itself supports this feature, I believe, check into that. That the feature of the DTS file is not supported by your version of TGEA.

…and is this the only ‘example’ fileshape, that causes this assertion error, in Debug build? I have heard another report about a HD dts shape crashing the engine, but can't remember at moment which build of engine, but I am pretty certain it was in a ‘deBug’.exe, where this occured; while a ‘release’ build functioned fine, also look into that perhaps.

DrFrankenRex, I bow at your feet!

The DEBUG build has the issue. However, the RELEASE build worked fine. Also, I used the same detail map shape.

I will head on over to the GG Forums and update this.

Thanks for your help!

Ron

DrFrankenRex, I bow at your feet!

The DEBUG build has the issue. However, the RELEASE build worked fine. Also, I used the same detail map shape.

I will head on over to the GG Forums and update this.

Thanks for your help!

Ron

Ya…goofy, how a ‘release’ version is NOT crashing the engine; while the ‘deBug’ version is….I'd keep hammering away from that vector.

? What is going on in the debug binary that is not happening in the release version, and does it matter, if the ‘release’ is not crashing to desktop?

Try to get an ‘official’ answer from a GG employee on this, be great to know what is going on here….

DrFrankenRex
Ya…goofy, how a ‘release’ version is NOT crashing the engine; while the ‘deBug’ version is….I'd keep hammering away from that vector.

? What is going on in the debug binary that is not happening in the release version, and does it matter, if the ‘release’ is not crashing to desktop?

Try to get an ‘official’ answer from a GG employee on this, be great to know what is going on here….

Just to update. The failure in debug is critical, meaning it crashes. In Release there is a bounding issue where you can run into the object (ring) and you will get stuck. So although you may place the object in Release, you will have issues later on.


The issue is not there in TGEA 1.7 only 1.8 (so far in my testing). Does anyone know (sidefx employees help) if the Houdini exporter has changed at all in the last couple of builds?

The last update of the DTS exporter I see is in June 23 2008.

The solution for me was inside the Torque Render node I select use custom bounds and created my own bounds box. Seems there may be an issue with how Houdini is exporting the bounding box, shows fine in Showtool Pro but not in TGEA.

At least that gets my models in TGEA with no crashing in Debug, Release works, collisions work and it seems that it renders fine.

Here is test I did creating my own bounding box. Others are free to use it and test/confirm if that solves the issue. I submitted a BUG report to Houdini, so hopefully they can look at it and correct if the issue is on their side.

http://mag-tac.com/tempfiles/scope.dts [mag-tac.com]

(BTW.. I hope posting this link is not against the rules. Haven't read em in a while

Ahhhh, auto bounds…ugh. I always build my own…and if I remember from the DTSplus! exporter with auto bounds creation, it ‘padded’ the shape's dimensions to put the bottom of the box, below the ground plane; and this was not good, as it artificially ‘lowered’ the origin to below ground level, making objects ‘sink’ into the terrain. I bet the same bit of code is doing something similar, perhaps? Padding the dimensions, obviously not autogenerating correctly.

Glad to see you kept at it, and let me get this straight so I can commit it to memory; this same shape with auto bounds generation…was NOT crashing TGE 1.5.2, not crashing TGEA 1.7x only crashing TGEA 1.8? And any ‘custom’ bounds was clean in all versions?

Thanks.

No. I need to correct my above statement. The reason it was not showing up in TGEA 1.7 was because I had, and most others had created the bounding boxes ourselves. It is present in 1.7, 1.8 and I will assume TGE though I have not tested.(I just retested before posting in 1.7 to double check).

Sorry, should have clarified. Yes, if you create your own custom bounds, you should be fine. I looked at the bound and I did not see anything out of the ordinary, but now that you mention that, might be something to look at.

Yes, I noticed oddity with the DTSPlus! exporter for Milkshape3D and auto generate a bounds. This may be a place for a start in cleaning up the code.

Glad you clarified things, always hard to localize where the bugs is start thru public Threads.
I maintained robotic lighting fixtures and when they would bring me a light; I always started with, “what's it doing/what's it not doing”….helped narrow things down quickly, as you begin to see ‘trends’ in breakdown over long periods, as I'm sure you're aware if you do this for a living, .

I'm also running a very early version of Apprentice HD and the ROP, I believe it has changed perhaps once since the gold release of 9.5.146 , as there have been many ‘public’ builds since then and I have no idea of the inner workings of the script side of the program. And this version even says ‘Public Beta’ on the splash…guess it's time to download another release version…

Good luck out there!

Oh yes. I troubleshoot CAD and integrations and pass solutions to IT (or the problem). What I love is when I contact a user about their trouble ticket that states “Can't load model”. After 5 emails the answer is still “It just wont load, Dick Tracy, figure it out.”

Ticket closed. Solution ID10T error….


Take care, see ya in the threads….

This issue should be fixed with tomorrows daily build of Houdini (9.5.339). The Torque exporter incorrectly translated bounding boxes from Houdini's co-ordinate system to Torque's. We have pushed the fix back to GG.

Hey Derrick, thanks for the quick response!

When you say you have pushed the fix back to GG, what exactly does that mean?

Again, thanks..

Magnum
When you say you have pushed the fix back to GG, what exactly does that mean?

GG is responsible for developing and maintaining the Torque exporter. Once the source of the bug was identified and found simple to correct, we fixed it on behalf of GG and gave them the changes.

Kool. Thanks, wasn't sure who actually owned the exporter so that helps.