Limitations with DTS Shapes

#1 Continued..
Okay, at the moment, my knowledge of Torque is limited, and I accept that, and I may have to look at tweaking the code source to get the results that I want.
However, in just one instance I have spent several hours building just one relatively simple object in both DIF and DTS format. Neither was satisfactory.
Before purchasing Torque, I had presumed from the demo, and even Tribes 2, such simple things as shape collision and shadows would have been part and parcel of the package and not as limited as they are.

Don't get me wrong. I really appreciate the community and I have learnt a hell of a lot since purchasing Torque from the various posts on this forum and I thank the authors for sharing their information.

However having spent the past twelve months planning my project and creating a large number of vehicles, static objects and other stuff for the project I did expect that a commercial engine would have the basics such as object collision and shadows addressed.

For the technically curious I am running a P4 1.6 MgHtz with Geforce 3 MX and 640 MB RAM, and games such as Call of Duty and Operation Flashpoint run okay.

#2 I don't understand, my vehicles cast shadows. Some emap setting in the datablock I think? Not sure. I looked at my tank *.cs file and it does not have this set, but does cast shadows. player.cs file does have this set. Maybe staticshape does not support this?

I have run into the collision limitation on collision meshes when building a colloseum out of a DTS. I never expected this to work and just did this for the fun of it. I plan to try using Quark to fix that. As of yet, I have not built a DIF. I can't comment on your problems with that.

You can connect multiple DTS objects together by putting mount points in them and mounting them togther on insertion into the engine. This could make for some destroyable bridges that come apart by unmounting pieces off of it. Could make for some complex objects that can be blown up. This could be very interesting. This should allow you to "extend" the number of collision meshes you have for a single object. It would require some planning and experimentation however. I have built a vehicle and mounting wheels on it using mount points. I did my dts creation in Blender so I cannot help with any Max issues.

Frank

#3 This may be helpful:

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5502

Not limits on the collision meshes...I can't speak to performance just yet though. I am in the process of updating this to include a much more robust collision scheme (should approach dif performance). This will take me a few weeks though. There has been some interesting discussion on building this into a little easier level editing pipeline (.map->.3ds convertor and such) but no hard plans made yet.

Generally the misaligned brushes thing is caused by Quark exporting coordinates in integers instead of floating points. There is an option somewhere to make sure it exports in floating point. You should also make sure that you have a fresh copy of map2dif. There are older versions floating around that do not support floating point and will introduce the same kind of errors.

#4 You will find the floating point option in Quark in the "Options" menu under "Configuration..."

From there you'll find it in the Map - Options section. Its the second to last selection on the right side of the screen.

#5 Hi Matthew.. talk about timeliness :) The DTS thing was driving me batty. Thanks I will have a look into this.

@Matthew and Kevin. Not sure of the version of Map2Dif that I've got, I presumed when it downloaded with the Torque tools it was the latest version.

I remember somewhere stating to tun off floating point in configuration and I had done that.
Cheers.

#6 Hi Bob,

Sorry that you have been frustrated. Such is gamedev, no matter what tools you use. (Which is not to belittle your problem. I fully agree that the older systems could be quite cumbersome in certain situations.)

I'm glad that there are some viable solutions to your problem. As for Quark and the floating-point issue, you are correct-- we are currently working on updating the Map2Dif and Quark documation. I'm sorry if out-of-date information caused confusion.

Anyway, I'm glad there was a solution. The forums rock. :)

#7 Hi Josh. I guess my background in VB could be causing a bit of consternation. Also the long hours over one problem got me a bit worked up.
I have tried the floating point option and it does look a lot better.
Thanks.

#8 DTS shapes can't cause "lag". "lag" is a network term and has nothing to do with 3D geometry.

DTS shapes can affect the overall performance of the application if used incorrectly or overload the hardware, and affect the frames per second because of they are not designed to do certain things like buildings.

So it is impossible for DTS shapes to cause "lag".

DTS shapes are not designed for use as buildings and structures that are require sophisticated collision.

DIF shapes are designed for sophisticated collision.

#9 From where I come from, 'lag' means slowing down or a drop in performance. It is often used to describe bad network latency, but that is certainly not the only thing it is used to describe. It is also often used to describe a significant drop in 3D performance. Either way its just semantics and not a terribly useful argument.

From my own poking around, I found that the DTS objects are probably too general purpose, and have a lot of stuff in the code that is not useful for most applications. I think it would be better served to have different specialized formats for static shapes, animated shapes, vehicles, players, etc. so that the performance issues can be tweaked for each. With today's hardware you should definitely be able to add shapes with a few thousand polys to a scene without the kind of dramatic performance drops that I see with DTS.

For instance, if I try to add a 6000-poly tree to a scene, with a single-textured DTS file it drops my framerate down to about 3-4fps when the tree is in view, which is obviously utterly unplayable. I am playing around with creating some new object types, and using basic OpenGL vertex arrays I can add that same 6000 poly tree to the same scene, multitextured, and the performance drop is much, much less; I still get around 40-50fps with the tree in view, which is still acceptable. I still don't have the collision detection working the greatest yet, but the collision detection should have no effect on the framerate if you are not close to the object.



Peace

#10

Quote:It is often used to describe bad network latency, but that is certainly not the only thing it is used to describe. It is also often used to describe a significant drop in 3D performance.

If it is used to describe a drop in performance of an app, especiall in frames per second caused by anything other than network latency it is incorrect.

Lag has always meant one very specific thing. Excessive transmission times in a network communications context. This term was defined WAY before 3D graphics existed and way before all the un-educated game players mis-appropraited the term to mean just about anything they did not understand.

Words have very specific meanings, ESPECIALLY technical JARGON words to dis-ambiguate discussions of technical terms. If it is not so important then everything can be refered to how every the referrer wants and nobody would have any common ground to discussion SPECIFIC technical issues.

Saying that DTS shapes cause lag is saying that it is affecting the network transmission latency which is INCORRECT.

#11 Well, I don't want to turn this into a war over a word, but I have been in this business (both computing and programming) for a very, very long time. And what you are trying to assert is a very narrow view, and makes it apparent that you are coming out of the network industry, which I have more than 10 years under my belt in myself.

'netlag' is a technical jargon word, 'lag' is not; it is a general term that has different meanings depending on the context. In the *networking* industry, netlag has been reduced to just 'lag', IF it is not qualified. However, the qualification in this guys post was obvious, since he was not talking about networking at all. There was no ambiguity as to what he was referring to.

Peace

#12 Man that piss has a lot of hang time!
I officially dub the measurement of piss hang time during a pissing match to be: pisslag. While this will technically be a unitless measurement as it will be based on personal interpretation of the discussion at hand.

Thanks,
Frank

#13 I have been working with computers since 1978 and after using some rather slow and tired computers over the years, "lag" to me is the abhorrent slow screen update as the player moves.
In a 3d application such as Torque I would expect that having just a few 3d objects, dts, or for that matter any other file format, shouldn't cause such a large unacceptable drop in frame rate.
I have just tested a 6587 polygon helicopter I built in operation flashpoint and even with 5 other choppers flying at the same time there was no significant drop in frame rate. Now if I was to do the same in Torque, going by the drop in frame rate caused by 1000 or so polygons in my bridge, Torque would freeze up completely.
While dif format will be okay for interiors and some of the buildings in my project, because the project is based primarily outside, I think the issue of dts "lag" needs to be addressed.
I have tried the new 3ds models and it looks good, but at the moment I am still contemplating my next move. I'm looking seriously at the idea of a new file format, but as this will take time I cannot put the project on hold while I explore that option.
I purchased Torque based upon what the demo information gave me, no more no less.

#14 Generally speaking with a 3D online game you can have roughly 4 types of lag.

1. Render lag - Your video card just can't keep up with what is being thrown at it and it drops frames.
2. CPU lag - Your processor can't keep up and the whole game slows down.
3. Network lag - Commands from you to the server take so long that you're off-sync with what is going on in the game.
4. Packet Loss lag - A form of network lag, generally your network connection to the server gets the information to you in a timely manner, but for some reason or other the packets are disappearing every so often.

#15 DTS shapes tend to eat performance due to render state changes. If you have lots of different materials, you can lose large amounts of performance...

#16 That being said, why then does Torque use a shape format such as dts. I am sure there are cases where dts shapes work quite happily, however I'm thinking that the dts shapes must be simple. The bridge span model uses one 512x512 texture and the screen update is worse than a side scroller on my old Atari.

In the example I gave above about the helicopter, the main texture is 2048 x 1024 plus it has numerous other textures weighing in at 512x512. I do realise the Torque engine and the one in Operation Flashpoint are totally different, however, my concern is that it appears that unless a game made in Torque uses primarily dif interiors, any other type of game that uses a lot of dts shapes will be rendered virtually unplayable.

I'm new to Torque, and new to c++ programming, and would like to substitute any file format that will give the desired frame rates that will ensure my project will go ahead, but at the present time I am stuck it seems with dts that is not workable for me in its present state.

Perhaps its not the dts shape that is the problem, but the Mesh Rendering Engine itself that perhaps needs to handle dts a lot more efficiently.

#17 Hi Bob,

I have had your same experience. I have been perplexed as to why a 'AAA game engine' would not have a format for models that can handle high poly counts. The only conclusion I came up with is that they just wanted a single general purpose format to consolidate all non-interior, non-terrain objects. However, it has been my experience that general purpose is not consistent with game development.

I really like Torque because it brings all of the elements of a game together, but the rendering and collision pipelines leave a lot to be desired. I haven't completely checked yet, but I have a suspicion that the collision detection doesnt do the obvious easy-out tests that would quickly eliminate polygons from consideration in the full collision detection. With my format, it seems like I can have as many polys as I want in a collision mesh, as long as I check against the collision bounding box before adding a polygon to the collidable polylist, it will give me quite acceptable performance.

So I have decided that my best bet would be to create a series of new file formats. I will be releasing the source code to both the engine implementations and the 3DS Max exporters as they become robust enough. So far the results have been really good, I think by next weekend the static model format will be good enough to release, and it might be, at a minimum, the answer to your bridge problem. I am also planning a new format for animated models, but that will probably be a bit longer in development.

The static model format can handle much larger numbers of polygons, and has an internal tree structure so that it will give you polygon-perfect collision detection without having to supply any seperate collision mesh; it will use the model's polygons as the collision mesh and the easy out tests make the collision checks quite fast as long as there is not TOO much concentration of polygons in small areas.

For instance, just for testing, I made a tube in 3D Studio Max with 5000 polygons, applied a bend modifier, and used the texture baking option to render the lightmaps. With a 512x512 tiled texture, and a 512x512 lightmap, I can have 5 of these in view at the same time, and still maintain 60fps on an AMD XP 2000 with a Geforce 2, with no noticable drop in framerate when walking inside of the tubes. I tried just one of these in DTS format with no lightmap, and it brought the game to a near halt just looking at it, and to get a collision mesh that would work anywhere near correctly would surely be an exercise in futility; my DTS test only used a bounding box for the mesh.

The downside is that they do not use the Torque lighting model, so when you create the objects in 3D Studio Max you will have to add a light in the approximate location of where your sun is in your game (obviously this means the day/night thing will not work right unless you render several lightmaps), to have consistent lighting. But considering the extra work you have to do to create DTS files, that isn't too bad. It also means that, for now anyway, shadows from mountains and such will not be cast on the objects, and the object will not cast shadows onto the terrain.

As I learn more about the Torque lighting model, I will try to create additional formats that will work with these other fringes as well.

The animated/dynamic models will have to take a different approach, as they will require some dynamic lighting to look right. A couple more weeks and I should have that all sorted out I hope. There will also be a new interior type, looking at probably a month before that is ready, as I have a lot of goodies I want to add.

I will be sure to post to this thread as they become available, so you can test them out.

Peace

#18 Hey guys,

I'll point out that file format is largely irrelevant. DTS happens to be matched well to the renderer, but they don't have to match up. Matthew Fairfax wrote a loader and renderer for raw 3ds shapes. I've written loaders and renderers for dumb text formats.

It doesn't matter much what the format is, but rather what your renderer is like.

Anyway, it's good to see people in the community working on new rendering tech. :)

Feel free to start a new thread for your poject.

#19 Gerald,

Have you tried your collision scheme against a vehicle?

#20 Hi Matthew,

Actually that is what I am working on right now, just to see how it works in comparison. I have never actually used the Torque vehicle feature yet, so I'm not positive how well it will work. From what I have read it is obviously more CPU intensive, but I have some pretty good ideas for reducing it based on what I see so far. I'll let you know how it works out, hopefully sometime today.

Peace