All DTS Building Content Pack... Practical???
by David Mac · in Torque Game Engine · 04/24/2005 (8:53 am) · 22 replies
I've been putting together a building content pack for TGE. I don't like Quark, don't have Gamespace or Cart. I thought I would try and solicit some feedback from the community to see if there is intrest in an "all DTS" format building pack, or is DIF going to be required? (Yes, the pre-DTS converted objects could be included in the pack in OBJ, 3DS, and MS3D format).
As I understand it, the main reason for using DIF instead of DTS is a clipping issue on large objects. (Or am I mistaken)? I run my own TGE character models at 2.5x the scale of the stock TGE orc and have experienced no clipping or other visual abnormalities with my buildings at that scale.
ATM I'm working with a mideival motif and none of the structures are over 3 stories tall. I could see the need for using DIF on a 40 story skyscraper, but are DTS format buildings commercially acceptable for 1 to 5 story structures???
At what size does clipping become an issue? I've read "larger than screen". But at some point, most structures will appear larger than screen. How is "larger than screen" determined?
Thoughts?
As I understand it, the main reason for using DIF instead of DTS is a clipping issue on large objects. (Or am I mistaken)? I run my own TGE character models at 2.5x the scale of the stock TGE orc and have experienced no clipping or other visual abnormalities with my buildings at that scale.
ATM I'm working with a mideival motif and none of the structures are over 3 stories tall. I could see the need for using DIF on a 40 story skyscraper, but are DTS format buildings commercially acceptable for 1 to 5 story structures???
At what size does clipping become an issue? I've read "larger than screen". But at some point, most structures will appear larger than screen. How is "larger than screen" determined?
Thoughts?
#2
1. By default you are limited to 9 collision meshes in Torque, which means that your buildings will have a very simple amount of collision data to them. You can increase the number of collision meshes that Torque uses, but this in turn takes up more memory.
2. The larger (physical size) the DTS collision shape is the more processor intensive it is. This is because the engine needs to check the shape versus everything in the area, so it has to do more collision checks than a DIF based shape would require.
3. Very simple collision shapes, you are limited to 28 polys or less if you even want to try to keep the engine performing well.
4. Like William Sims said, lighting just doesn't work out too well... in fact it plain sucks.
04/24/2005 (9:07 am)
To be honest I dont think that this would be good. We tried this for a while with Lore Invasion and there were too many negatives to outweigh the positives, which I will outline below:1. By default you are limited to 9 collision meshes in Torque, which means that your buildings will have a very simple amount of collision data to them. You can increase the number of collision meshes that Torque uses, but this in turn takes up more memory.
2. The larger (physical size) the DTS collision shape is the more processor intensive it is. This is because the engine needs to check the shape versus everything in the area, so it has to do more collision checks than a DIF based shape would require.
3. Very simple collision shapes, you are limited to 28 polys or less if you even want to try to keep the engine performing well.
4. Like William Sims said, lighting just doesn't work out too well... in fact it plain sucks.
#3
1)The collision mesh is No longer an issue with Torque 1.4, you can have unlimited collision meshes
04/24/2005 (9:20 am)
Just a note1)The collision mesh is No longer an issue with Torque 1.4, you can have unlimited collision meshes
#4
1) As Anthony mentioned, no longer a factor in 1.4.
2) Yes, but you can certainly work out some dts optimization to minimize these checks.
3) No longer a factor in 1.4.
4) Lighting can be fixed--the .dts shape needs to "catch up" in a bunch of ways, and code just needs to be written for it.
Now, here's why .dts shapes have advantages over .dif:
1) No pre-execution collision calculations required. This does two things for you:
A) You can have players dynamically use .dts shapes to build objects in your game, either by simply placing them (with appropriate interface code), or even linking multiple .dts shapes in a "lego" style connection capability.
B) You are limited to the convex only requirements of .dif's. .dif's are great for full interiors in the old style of gameplay, but external scenes can be pretty limited by this without careful art asset design. I'm not saying that it can't be done, don't get me wrong, but there are some additional freedoms that .dts style shapes allow you to have.
2) You can break the .dif structures down into smaller portions, and this will allow you to have more "immersion" style gameplay if your game allows for the destruction of buildings/environment around you. Historically this hasn't been a big factor in Torque games, but it's a big gameplay advantage in games as a whole.
These are just my personal opinions, and don't represent any implied expectation of GG supported code/shape enhancements!
04/24/2005 (10:57 am)
I'll go the reverse of what Logan (Foster) has to say, hehe:1) As Anthony mentioned, no longer a factor in 1.4.
2) Yes, but you can certainly work out some dts optimization to minimize these checks.
3) No longer a factor in 1.4.
4) Lighting can be fixed--the .dts shape needs to "catch up" in a bunch of ways, and code just needs to be written for it.
Now, here's why .dts shapes have advantages over .dif:
1) No pre-execution collision calculations required. This does two things for you:
A) You can have players dynamically use .dts shapes to build objects in your game, either by simply placing them (with appropriate interface code), or even linking multiple .dts shapes in a "lego" style connection capability.
B) You are limited to the convex only requirements of .dif's. .dif's are great for full interiors in the old style of gameplay, but external scenes can be pretty limited by this without careful art asset design. I'm not saying that it can't be done, don't get me wrong, but there are some additional freedoms that .dts style shapes allow you to have.
2) You can break the .dif structures down into smaller portions, and this will allow you to have more "immersion" style gameplay if your game allows for the destruction of buildings/environment around you. Historically this hasn't been a big factor in Torque games, but it's a big gameplay advantage in games as a whole.
These are just my personal opinions, and don't represent any implied expectation of GG supported code/shape enhancements!
#5
That's a lot of great information there.
So...
The number of collision meshes and collision mesh poly count is not an issue in V1.4.
Large DTS Shapes sap processor resources unless optimized. Any elaboration on what the "optimization" might be would be most appreciated ;] I'm going to assume minimal poly count for the moment.
DTS lighting "code" needs to be written. At what level? Is this a GG coding project for TGE, something that I would have to do, or is it something the average content pack user can program. Sorry, I'm an artist. My coding is limited to:
{
print("Hello World");
}
:">
04/25/2005 (11:38 am)
Thanks guys!That's a lot of great information there.
So...
The number of collision meshes and collision mesh poly count is not an issue in V1.4.
Large DTS Shapes sap processor resources unless optimized. Any elaboration on what the "optimization" might be would be most appreciated ;] I'm going to assume minimal poly count for the moment.
DTS lighting "code" needs to be written. At what level? Is this a GG coding project for TGE, something that I would have to do, or is it something the average content pack user can program. Sorry, I'm an artist. My coding is limited to:
{
print("Hello World");
}
:">
#6
The lighting code isn't a trivial change, and also isn't something that GG has even on the far horizon as far as I am aware, so it would have to be a community contribution--and might be a cool part of this pack if you can find a partner interested in that type of thing (and unfortunately, it's not on my project's milestone list for quite a while, so it won't be me).
Also keep in mind that the 1.4 code doesn't make it "not an issue", it simply moves the restrictions on the numbers. It still can cause performance issues if you go way overboard in dts collision meshes.
TGE has "levels of detail" available to you with .dts shapes that basically allow the code to auto-magically switch to a (provided by the artist) lower poly model based on the screen height of the overall shape. That is your primary optimization there that is artist controlled.
I want to disclaim my post above as well: all of the things I mentioned are way "out of the ballpark" for stock TGE, and currently there aren't any plans for GG to develop and support anything like that, so without a strong and experienced in TGE coder, I wouldn't strive for achieving any of them...
04/25/2005 (11:54 am)
One thing that wasn't mentioned, but dts shapes cull themselves out of the scene entirely if their center is not within the field of view. So, for very large dts shapes, you will need to break them up into pieces, or adjust that code as well.The lighting code isn't a trivial change, and also isn't something that GG has even on the far horizon as far as I am aware, so it would have to be a community contribution--and might be a cool part of this pack if you can find a partner interested in that type of thing (and unfortunately, it's not on my project's milestone list for quite a while, so it won't be me).
Also keep in mind that the 1.4 code doesn't make it "not an issue", it simply moves the restrictions on the numbers. It still can cause performance issues if you go way overboard in dts collision meshes.
TGE has "levels of detail" available to you with .dts shapes that basically allow the code to auto-magically switch to a (provided by the artist) lower poly model based on the screen height of the overall shape. That is your primary optimization there that is artist controlled.
I want to disclaim my post above as well: all of the things I mentioned are way "out of the ballpark" for stock TGE, and currently there aren't any plans for GG to develop and support anything like that, so without a strong and experienced in TGE coder, I wouldn't strive for achieving any of them...
#8
04/26/2005 (11:17 am)
I think a dts building pack would be great... So long as they were small biuldings like houses and stuff like that. I would definately have intereste if the buildings were general enough that my artist could expand them into what we want them to be.
#9
Here's a real quick screenie of the buildings I have already completed in all their DTS glory from inside TGE. An "Orc's eye view" so to speak...
Keep in mind that they aren't done yet. Textures still need tweeking, scaling, weathering etc... and some of the faces I KNOW were faced correctly in the renderer, flipped on export to DTS, so I have to fix that too.
http://purgatory7.bravehost.com/Mideival_City_Big_01.jpg
The current trend seems to be no remote image linking, so you'll have to manually go there. Sorry.
I am toying with a more modular design, but want to get the basics down 1st. The final product will include over 25 individual building meshes, and accessories such as trees, fences, dirt roads, barrels, and such. I have 5 genre' motifs planned, but one at a time ;]
04/26/2005 (11:37 am)
Hehe, well... Here's a real quick screenie of the buildings I have already completed in all their DTS glory from inside TGE. An "Orc's eye view" so to speak...
Keep in mind that they aren't done yet. Textures still need tweeking, scaling, weathering etc... and some of the faces I KNOW were faced correctly in the renderer, flipped on export to DTS, so I have to fix that too.
http://purgatory7.bravehost.com/Mideival_City_Big_01.jpg
The current trend seems to be no remote image linking, so you'll have to manually go there. Sorry.
I am toying with a more modular design, but want to get the basics down 1st. The final product will include over 25 individual building meshes, and accessories such as trees, fences, dirt roads, barrels, and such. I have 5 genre' motifs planned, but one at a time ;]
#10
04/26/2005 (11:40 am)
Im sure someone would be able to find a good use for htem. If you already have the buidings ready to go in dts format then why are you asking if you should do them in dif? Continue your dts work.
#11
I'll try and import what I have done already into Quark, re-texture it, and export to DIF. Hopefully, it won't loose too much in the process.
I should also add that the buildings range from ~60 polys to 577 polys including collision meshes. I haven't added LOD yet. Most buildings are between 100 and 300 polys.
04/26/2005 (11:51 am)
It seems that DIF provides superior lighting options and less processor resources. I don't want folks deciding not to get the pack because it's done in DTS. I'll try and import what I have done already into Quark, re-texture it, and export to DIF. Hopefully, it won't loose too much in the process.
I should also add that the buildings range from ~60 polys to 577 polys including collision meshes. I haven't added LOD yet. Most buildings are between 100 and 300 polys.
#12
04/26/2005 (12:38 pm)
Looking good. I especially like the windmill.
#13
04/26/2005 (3:20 pm)
And given especially the poly counts you mentioned, those should be pretty perfect for the RTS-SK requirements (buildings need to be .dts), so assuming that you make buildings with that type of game in mind (not even a specific genre necessarily, although sci-fi/modern, fantasy, etc. all have their benefits), they would go pretty well for that environment.
#14
@Stephen; Well, I see that there appears to be advatages to both formats then. If I can import the native objects into Quark without too much trouble, maybe I'll try and provide both DTS and DIF, as well as the standard 3DS, OBJ, and MS3D formats. That should please just about everyone ;D
The Genre's planned are currently:
Mideival
Old West
Modern
Futuristic
Fantasy
I may also include a generic Eastern motif and have been toying with the idea of a castle/fortress pack add-on to some of the above. I want to see how at least one content pack works out before going hog-wild though.
Time permitting, I may also include interior modules as well. These will probably be done in DIF, (I can't see interiors being used in an RTS, but you never know).
Thanx again to everyone for all the great feed-back.
04/26/2005 (5:23 pm)
@ David; Thanx for the kind words!@Stephen; Well, I see that there appears to be advatages to both formats then. If I can import the native objects into Quark without too much trouble, maybe I'll try and provide both DTS and DIF, as well as the standard 3DS, OBJ, and MS3D formats. That should please just about everyone ;D
The Genre's planned are currently:
Mideival
Old West
Modern
Futuristic
Fantasy
I may also include a generic Eastern motif and have been toying with the idea of a castle/fortress pack add-on to some of the above. I want to see how at least one content pack works out before going hog-wild though.
Time permitting, I may also include interior modules as well. These will probably be done in DIF, (I can't see interiors being used in an RTS, but you never know).
Thanx again to everyone for all the great feed-back.
#15
I know that even after 8 months of working on our RTS mode for our project, we are still stuck using much of the prototype art that was provided by GG, and a couple of other very minor prototyped buildings done by the RTS-SK community...and I can only imagine that there are other projects in the same scenario!
@David: If you (or anyone else for that matter) is thinking about providing content packs for RTS like this, please feel free to contact me privately via email (in my profile) if you want tips/tricks for your building models, or would like a test RTS environment to have your buildings tested out...I'd be more than willing to offer up some time with our project for it!
04/27/2005 (3:23 am)
I obviously can't promise massive sales or anything, but in my personal opinion, one of the things holding folks back from making RTS's (even with the RTS-SK) is the fundamental lack of dts artwork designed for RTS's. I honestly think that while you wouldn't get a lot of sales right off the bat, providing prototying content kits designed for RTS's would be an continuously growing market.I know that even after 8 months of working on our RTS mode for our project, we are still stuck using much of the prototype art that was provided by GG, and a couple of other very minor prototyped buildings done by the RTS-SK community...and I can only imagine that there are other projects in the same scenario!
@David: If you (or anyone else for that matter) is thinking about providing content packs for RTS like this, please feel free to contact me privately via email (in my profile) if you want tips/tricks for your building models, or would like a test RTS environment to have your buildings tested out...I'd be more than willing to offer up some time with our project for it!
#16
04/27/2005 (8:24 am)
I agree with Stephen that having building packs in dts format would be a large boon to any current or prospective RTS builders out there.
#17
An FPS pack should probably be DIF, though.
04/27/2005 (2:56 pm)
An RTS building pack would be very appropriate in DTS, esp if the buildings had "build" and "damage" animations.An FPS pack should probably be DIF, though.
#18
I wouldn't mind putting in a rubble version of each structure though. That's doable. I'm sure a clever programmer could then make a convincing destruction sequence utilizing partical effects. (a flash of light and some smoke perhaps).
I like the idea of making a "lego" type content kit, but I think I might save it for V2. That will give me the opportunity to see how everything fits together, and identify common components that would become the "blocks".
As I mentioned earlier, I am now leaning towards a pack that has both DTS and DIF. Something for everyone! It may have some pretty cool software enhancements as well, but I don't want to get too far off topic by discussing them here.
To everyone; Again, I appreciate all of your comments!
04/28/2005 (8:16 am)
One of the things I like about static structures is that they are compairatively quick and easy to build vs animations. I enjoy 3d sculpting, but for me personally - animation is a chore. I think I may also lack the tools to create convincing effects on a damage animation. I did a model yesterday that I really wanted to put flowing water on, but I just couldn't figure out a way to make it look good within the limits of my current, low budget 3d software ;D I think I would end up with similar instances were I to try some nicely destroyed buildings.I wouldn't mind putting in a rubble version of each structure though. That's doable. I'm sure a clever programmer could then make a convincing destruction sequence utilizing partical effects. (a flash of light and some smoke perhaps).
I like the idea of making a "lego" type content kit, but I think I might save it for V2. That will give me the opportunity to see how everything fits together, and identify common components that would become the "blocks".
As I mentioned earlier, I am now leaning towards a pack that has both DTS and DIF. Something for everyone! It may have some pretty cool software enhancements as well, but I don't want to get too far off topic by discussing them here.
To everyone; Again, I appreciate all of your comments!
#19
The benefits of that are huge though if you can get it going! Always nice to be able to upgrade and destroy buildings in an RTS.
04/28/2005 (8:24 am)
As you mentioned, inclusion of both "being destroyed" and "being constructed" models for each base structure is pretty key for most RTS style games. 1 of each would work great, as would "upgraded" versions if the building gets "upgraded" in a game--but as soon as you start adding in the models for that, you start talking about quite a few models that can require a lot of work if you don't have a good system in place for the actual modelling work itself.The benefits of that are huge though if you can get it going! Always nice to be able to upgrade and destroy buildings in an RTS.
#20
Still, it appears there is some interest, so maybe I should find some room on my plate for an "RTS specific" pack.
I'll need more coffee! :D
04/28/2005 (9:00 am)
Hehe, When you start putting together 6-8 versions of each building and throw in animations, I think it evolves into a new project all it's own.Still, it appears there is some interest, so maybe I should find some room on my plate for an "RTS specific" pack.
I'll need more coffee! :D
Associate William Lee Sims
Machine Code Games