DTS instances in CartShop DIFs

#1 How about this possibility:

The artist can use a "proxy" mesh that will reference the DTS filename (thus eliminating the need to convert the original DTS into a CSM prefab).

This mesh would be a low-poly version of the actual DTS model and would serve as a collision hull.

Also, if the lighting could be enabled on this shape (afterall, it's part of the DIF so it should work) then you would have proper lighting/shadows too.


So ideally, this is how it would work:

1. You open your model in Maya, Max, Milkshape, or whatever, and then you make a low-poly version of it (a convex collision mesh). (Or just make it in CS if you want)

2. You import this proxy model into CS and set the properties so that it references the actual DTS file.

3. Then you set the texture to "collision_brush" or "null" so it doesnt render in-game.

4. Now copy/paste this model where ever you want it throughout your interior, rotating it, scaling it, etc.


Now if this shape can be set so that, although the surface is null/collision_brush, it will still shadowmap then that could solve the shadow mapping problem too.

#2 @Will - I see where you coming from on this, but my concern is that it seems like an extra step that just makes the process more difficult. We wouldn't need this to have collision or shadows... the only thing it would do is save some memory when editing in CS which could be a problem if you have alot of high triangle count duplicated meshes. IMO the best approach is to just add the code to cast the light mapping rays thru the meshes... it just has to be done at some point. Please correct me if i've misinterpreted your idea here.

But you do bring up a good point. In CartShop5 we would have the option to write a DTS reader. This would mean CS5 would see a DTS as a compatible mesh format and can insert instances of the mesh as desired without any DTS->CSM step. These would be true instances too... no duplicated geometry in the scene, real position, rotation, and scaling info.

Again to do this in CS4 would be a hack job to make due until 5.

#3 Okay, I re-read your initial post and I understand what you mean about collision.

But for lighting... as an alternative to having to code it in to work... is there a way to make shadows without a visible shape?

Like, I mean you make a shape/box and it's invisible but it still casts a shadow.

This would be useful not only for making shadows for DTSes but also for manually "painting" shadows where ever you want.

The DTS has to have a corresponding collision brush mesh anyway, right? So can this same brush/mesh be used to cast a shadow?

#4 Something along the lines of UnRealED's system would rule. :)

#5 @Will - Well at the moment no... if it isn't visible, the lightmapping process won't create a shadow with it. I could probably fix a special classname for brushes that only act as shadow occluders during lightmaping if this is an important issue (quake1 had shadow occluder brushes).

Even though you could use the DTS collision to cast a shadow... why would you when you could use the DTS itself. Let me be clear this isn't for dynamic shadows, but only for generation of the lightmaps.

#6 @Timothy - That's the plan... we just got done doing some contract work with Unreal2 and missed the ease of static meshes. I really like Torque, but the World Editor stinks for placing alot of DTS shapes in very specific positions.

#7 "why would you when you could use the DTS itself."

Okay, i thought it wasnt doable that way. lol, nvm!

:)

Still, being able to paint your own shadows would be cool... if it's easy to make it work.

#8 @Will - I'm still planning on passing the CSM thru Gile[s] which does have features for painting on lightmaps.

#9 I've been pondering some type of instance system myself, mainly for proper positioning and later in-game movement of, minor details such as wall lamps.
I'm considering allowing dts objects to have a parent, in this case the dif. Upon loading difs and dtss, we check if the object has a parent. If so, the coordinates are in object space relative to the parent, rather than worldspace. For cheap and dirty placement, I was thinking about hijacking mirror placement code, which basically allows a single point to represent the plane we wish the object to be placed on.
Quark currently supports basic .md3 loading, I'm sure a delphi wiz could expand this to .dts as well.
For simplicity, map2dif could just spit these entities out as a seperate text file. Minor adjustments to TGE/TSE, if we load house.dif via mission.mis, we look for house.children as well, executing it the same as the mission file.

#10 @Erik - None of this should be very difficult. My concern is making sure that whatever method is used ends up part of HEAD. So i want to cooperate with the GGs folks and get their input on how they would like to see it happen. Two things must be decided:

1. A way to represent DTS instances in the DIF file.
2. How to parent the TSStatic objects to the DIF.

Ideally i'd love to just change the DIF file format adding DTS instance data into it. Realistically we should try to do it without breaking the DIF format. I was thinking of maybe using GameEntity objects which contain the shapeName, position, rotation, and scale. As far as i can tell GameEntity isn't used at all in the engine and this would keep from breaking the existing DIF format.

On the rendering side i think changing TSStatic is too disturbing to the engine and anyone else's modifications. I insted suggest a new object derived from TSStatic... TSInteriorStatic or something like this. It would contain the parent pointer and know how to cull/render/collide relative to it's parent interior.

Again regardless of what direction is taken i stress how important it is that it ends up in the engine HEAD for all to use.

#11 @Tom,

What about the MIS mission file? This already contains instancing information for all DTSes.

What if, in the exporter dialog, you had an option to save to an MIS file (or overwrite an existing one)... that way, all changes made with DTSes in CS will be updated into the MIS file.

This may save you from having to change HEAD.

I mean, MIS already has all of the relevant instancing information for DTSes, why not use it?

#12 @Will - I considered generating or modifiying a MIS file, but it seems really messy. The problem is that the MIS could have stuff you currently cannot edit from CartShop (terrain, water blocks, sky, sun, etc). I could maybe do some sort of #include to hook in another script with your DIF and DTS instances, but i haven't looked into it yet.

If CartShop5 goes the way it seems then it may be possible for it to completely replace the World Editor. In that case it would save MIS files.

#13 Terrain, water blocks, sky, sun, etc. could be set to their default values.

Or, if you were to overwrite an existing MIS, those values would already be set, and you would leave them, only adding in the DTSes that are placed in CS.

Really, IMO those things are not important when you're focusing on making interiors and getting DTSes in place... its just the background (sun, sky, etc.)... and you can always set them in the World Editor later.

#14 Well *maybe* we could add a specialy formatted comment around DIFs and DTSs placed by the export, but i have a feeling that the Mission Editor will eat those comments on the first save.

And yes you could just not worry about that then let it up to the user to cut and paste the final thing into a new mission file. But that sounds ugly.

#15 @Tom: the way that I am doing it right now:
- create a corresponding .mis file to a .dif by storing the filename of the mission file in CShop with a property
- the .dif you create should have a unique filename pattern (something like cshop_*.dif)
- the exporter injects the .dif (or .dts for that matter) in said .mis file by looking for the unique 'interiorFile' (or 'shapeName') by following this rule:
if the interiorFile or shapename is already there, then you delete the block and overwrite it with your properties. If it's not there then you just attach it.

This would give you the best of both worlds.

[edit] typos.

#16 I would really push for some type of 'child' system, no matter which way this ultimately goes. Embedded dts would of course work as well. The main reason, being later movement of the dif. If I need to move my dif later on, I really don't want to have to move all the dts details as well.
Game entity is a good possiblity as well, I hadn't thought of that. That was added when marbleblast code was merged back into map2dif.

#17 @Erik - I completely agree... it wouldn't be very productive if DTS instances were not parented by the DIF. I'm thinking a new TSInteriorStatic object is what is needed there.

I'm not familiar with game entity other than my brief scan thru the map2dif code. How would creating DTS shapes via game entitites in a DIF work? My guess is you can embed some sort of script into the entity which is then executed on loading of the interior.

#18 Game entities would work any way we like :) GG gave us a blank basically, just a chunk of info that is written to the dif, and read by TGE. It does nothing right now. It seems reasonable that we could pretty much fill it with the same info a mission load of a dts needs, and load it by directly calling whatever function TGE uses when it reads the mission file. I haven't recently read the loading code, but I'll bet everything needed is already done, and just needs a rearrangement of calling order.
Once a general loading is working, changing the params to mean object space of the parent shouldn't be much more difficult

#19 This all sound great. :) I cant wait to see what comes of it.

#20 @Erik - Have you gotten any further with this?