Collada instead of .dif?

#1 Collada doesn't support portals neither lightmaps (yet). Some users have reported that complex TSStatics now render faster than similar Interiors, and it's probably true since there's an increased potential for batching. Torque3D also has a few additions that reduce (but don't eliminate) the need for fine-grained portals: the depth-pass and the hardware occlusion queries. The depth pass prevents fillrate from being wasted on occluded surfaces, the waterblocks check if they are occluded before updating the reflection and lights will not render (nor update their shadowmaps) if their bounding volume is completely occluded. But true portals still do more, like preventing skinned meshes from being updated and bypassing the entire render process for non-visible objects.

#2 Collada does support lightmaps via a 2nd UV channel.

#3 Collada supports a lot more things than the DTS does, much of the promise of collada and torque is that you can potentially edit the DTS to incorporate more of the collada feature set (if you are smarter than me that is :p )

As a slight side question, is it possible to polysoup difs if they are contructed from prefabs consisting of imported dts shapes or do you still need to make a bunch of simple collision meshes? and secondly.. can you portalise even if your dif is constructed almost entirely of dts shapes.

I'm specifically thinking of twisty caves which require much more organic looking surfaces, or even very large dungeons for example.

#4 @Pat: I'm aware, but last time I checked it wasn't exposed to the material system yet, is it? But even if it is, in-engine relight support is another story...

@Bloodknight: The DIF portals will zone all objects in the scene. So in you could make a very basic portalised tunnel DIF and cover it with DTS/Collada meshes inside the editor itself. You could use polysoup for the parts' collision and have the DIF do only the zoning.

#5 Thanks for the feedback thus far. Perhaps I should have been a bit more clear with my post....

I want to make interiors and I would like to know the best way to move forward for use in T3D. What is the "future" for interiors and T3D? If dif's are the way to go, then I'll stick to constructor...

If I want to start down the learning path to create interiors like this: http://www.garagegames.com/community/blogs/view/17195 (Undercity), what direction should I lean towards?

Just point me in a direction and I'll head down that path...

#6 Polysoup on Collada objects seems to really suck for me. For instance, I created a simple doorway out of three boxes in 3ds max and exported out as Collada. I made the doorway fairly large, with Gideon xref'd so I made it large enough for him to fit through and then some. However, when I load the object into T3D and enable polysoup, Gideon can't fit through the doorway. The collision mesh is far away from the actual geometry, and he gets stuck.

#7 @Manoel

Actually Sickhead Games is working on a great little occlusion zone system which will replace the lack of portal zones from DIF (and will porbably work a hell of a lot better). Provided that they don't hit any awful show stopper bugs when this system is in place there honestly shouldn't be a need for DIF.

@Pete

I have been posting how the Undercity world has been made at the following thread in the Torque3D forums (www.garagegames.com/community/forums/viewthread/88845) which might help you. If you need any extra info just post there and I will try to provide what I can.

@Joe

There is no collision mesh for Gideon in the player shape. You need to look at the value called "Bounding Box" in the player.cs file to get a sense of actual physical size of the collision shape that that model is using (and which is generated in Torque).

#8 @Logan: That's awesome! I was thinking of how to setup something like that a while ago, by using a class that uses some pre-defined convex shapes to act as zones/portals you can place on the mission and hook them to the sceneGraph's portal system.

#9 @Logan: I was talking about the polysoup collision on my Collada object. I don't know how the collision mesh is generated for polysoup objects, but the mesh appears to stand out from the object quite a bit. Maybe I'm not wording it properly...if so, I'll take a screenshot later on to show you what I'm seeing.

#10 @Joe It seems to me that what Logan may be saying is that it's not the Collada object that's colliding wrong, but rather since Gideon doesn't have a collision mesh - rather a bounding box, then the bounding box may be what's hitting the Collada object. The bounding box probably extends quite a bit further out (or higher) from Gideon than a mesh would.

Maybe reducing the bounding box size or creating a collision mesh for Gideon? I dunno, but that's how I'm interpreting it..

#11 @Kevin

That's exactly what I am saying, thanks.

boundingBox = "1.2 2.0 2.3";

That's the size of the collision shape that Gideon is using (XYZ with Z being up), it should help Joe size his shapes bigger so that there's enough room (plus more to spare) for a player like gideon to fit through.

#12 Ahh ok. My mistaken interpretation I guess. Sounds like it's time for me to learn how to create character models for T3D (with collision meshes), export them, learn to do animations, and all that stuff.

Thanks!

#13 A good solution for you would probably be rendering the bounding box within the game while you are working with the design. I dunno if this can be done or not, but maybe someone else can clarify.

If not, then I suppose you could make your player a big cube the same size as what the datablock specifies as the bounding box so you could see where characters will hit their heads or other parts against your doorways.

#14 If you select the Player in the World Editor it will render his bounding box (look for the white corners).

The Player's bounding box is actually controlled by his datablock and not by the exported shape. You can find it in art/datablocks/players.cs

Before Torque 3D Beta 2, Torque had a problem where if your eye node moved so that the Player's bounding box then it would stop rendering the Player and more noticeable its weapon. So the easiest "fix" was to increase the size of the bounding box to make sure that the eye node stayed inside. Unfortunately, this meant that the Player's collision was really different from his visible mesh in a lot of cases (like with Joe's case or with the classic "floating" Player on sloped surfaces).

Now that we no longer have that issue, we are planning to tune all of the Players' bounding boxes to better fit their visible geometry. If anyone would like to lend us a hand, it would be much appreciated (we need new bounding box settings for Gideon, ForgeSoldier, BoomBot, and Spacesuit)!

#15

Quote:
Now that we no longer have that issue, we are planning to tune all of the Players' bounding boxes to better fit their visible geometry. If anyone would like to lend us a hand, it would be much appreciated (we need new bounding box settings for Gideon, ForgeSoldier, BoomBot, and Spacesuit)!

Already on it! Well, Gideon only so far... I've been using "0.8 0.8 1.9" for him. Seems to make things more fun when chasing bots or getting shot at :D Still a couple of unwanted side effects though, and so as not hi-jack this thread I've started another one here to discuss this further.

#16 Exporting Interiors to Collada - coming soon to a Beta 3 near you!



There are more details in this thread.

#17 Hey Matt - Looks great. Will the lightmaps export as well? Or will the DTS lightmapping make an appearance?

#18 Currently it doesn't export the lightmaps. It would be fairly trivial to do so but I expect that people would get much better results just running the meshes through a lightmapping tool (like pureLIGHT or a 3D Studio plugin or something else).

At this point we don't plan to directly support generating lightmaps for meshes/shapes in the engine itself. It is a tricky/difficult problem to solve and it is already solved by much, much better tools out there so we are concentrating on supporting as many of those tools as possible.

#19 another stupid question

are lightmaps needed if you use advanced lighting? i thought they were 100% dynamic, i'm not quite au fait with much of this stuff, as i'm transitioning from hobbyist -> indie -> billionaire (i'm at the - in the first -> :p)

#20 Having the light baked into a texture is ideal for areas (interiors) which wouldn't need the light changing based on sun positions etc.
Dynamic lighting is computationally expensive and shouldn't be used if not needed. One can have a mix too, no doubt, so that interiors can have some dynamic lights, even if most of the appearance comes from lightmaps.