Large, enclosed interior spaces

#1 My personal opinion, use sssomething ele, QUARK sucks ass. im sure there is somethig out thre more intuitive adn user friendly you can use besides that peice of crap.

#2 You'll have trouble with flowing curves in any medium. The amount of faces required will bring any graphics card to its knees. If players can touch the surface it needs to be done as an interior (Quark, hammer, cartography shop). If you create it in something like Max or blender you will have problems with the collision as most game engines cannot do colision on poly soup models.

#3 Other than Cartography Shop, there's not much else that's legal to use.

You could use Quark, bezier patches, and the Quake 3 engine. By the time you're ready for release, it should be GPL'd (depending on the product cycle of their new Q3 licenses that pushed back the source release). You'd have to release your source code, but all game data would be yours.

Of course, you could work on creating "curves" with Quark. Or you could write a 3DS (or any format) loader for polygon collision.

#4 Shape3ds

#5 I'm not sure quark is your best option for performance reasons, but in your case I'm not sure anything in Torque is setup to perform really well for your circumstances. You might make many dif segments to put together so culling will work properly. In terms of actually making curved surfaces, it's possible in Quark, but it'll take some work and experimentation. Check out the prism maker for one. You can make hollow tubes with it, even hollow cones, and elliptical hollow cones. Play around with it, be sure to read all the tooltips inside the make prism dialog box. You should be able to make your whole "M&M-drone" using this alone. Note that you need to have "make pie-slices" checked in order for hollow tubes to work well.

Another option to consider would be to write your own custom collision code (since a squashed sphere object as you describe is easy to represent mathematically) for your arena. Then you can use a 3ds object, as Matthew posted above.

Either option will take quite a bit of work.

#6 I was trying to remember the link to that! Thank's Matthew!

#7 Well, I have already developed the collision code (in the game engine I built on my own) that will check collision detection against every polygon in the arena (based on a bounding sphere and bounding box) however, it is all DirectX9 code, and is very integrated into my own engine. I do not know the Torque engine very well, and will basically have to rewrite the whole thing..

What is wrong with the dts collision? How does it differ?

As for the Quake 3 engine... I want to use Torque. I don't want to deal with legal issues that come with the Quake series engines.

I don't see how a hollow tube or cone is really going to help me... I will muck with QuArK again..... In my opinion this is one of the major areas that torque is lacking is the flexibility of which models I can use and formats...

If I could tesselate a sphere in Quark and then invert it (I know I can invert) then I could stretch and manipulate the vertices to something that will work with me... The only problem is I couldn't find a way to tesselate the (very basic 12 sided I think) sphere that Quark lets you use.

If anyone can tell me how to tesselate the sphere that would help... also, does that seem like it will work?

Most importantly though, what is the collision detection and response differences between difs and dts objects?

EDIT: What type of throughput can I look to achieve using dts objects or difs? I need to know how limited I am before I start building this using a specific method.

And players dont walk on the arena, they hover over it in hover sips... but inevitably I guess particle weapons will collide with it... I can try and get around ship collisions if I have to.

#8 Dif collision is much more optimized than dts. Dts does not offer per-poly collision. You must provide a convex collision object for dts (so you couldn't create your collision using dts anyway, really, because all of your surfaces are concave).

Quark is a very powerful tool, but you have to think different. Don't try to tesselate a sphere. Build it piece by piece. If you slice a sphere into several thin slices, you get cones (well, almost... good enough for games). If you slice a hollow sphere into several thin slices, you get conical tubes. So, slice your hollow sphere into say, 16 or 32 slices, and you have 16 or 32 conical tubes that you can piece together to make your object. Put caps on the end and you have your "M&M" shape. In my opinion, this is the quickest way (least amount of code modification) to accomplish what you're after. It's not the _best_ method, but it's one that will work, and quickly. If you're really struggling to understand this, I'll throw together a small sample of what I'm talking about.

You can even use DIF for collision, and set the textures to null so the DIF doesn't render, then use a DTS object as the graphical view of the object. So nothing collides with the DTS, only the DIF.

Oh, note that if you make a fully enclosed DIF, it won't render. You need to have a small leak somewhere, or a door.

#9

Quote:
Oh, note that if you make a fully enclosed DIF, it won't render. You need to have a small leak somewhere, or a door.

The new Map2Dif Plus fixes that limitation.

#10 Ok, that was really confusing... but you are suggesting that I build my arena in QuArK using sliced spheres, or whatever, just mess around until I figure out how to make it look the way I want. I guess that sounds reasonable, since it seems to be the only available tool to me. I will try it out, and see what happens...

So how do I get it to render with any kind of efficiency? How many polys can I push? how does culling work, I know what it is but how does it decide what to cull? Does this seem like a feisible way of doing things, or is it going to kill my performance?

#11 Now, to clear things up a little, what I am suggesting is to use the "make prism" tool in quark to make thin tubes. Basically like making a bunch of different sized rings and connecting them together to make a hollow sphere. My talk of the sliced spheres was just to explain the technique rather than the implementation.

As far as performance goes, that's getting out of my knowledgebase. I do know that complete interiors are culled if they are completely out of scope, so you could make all the pieces in separate map files, then load them into torque separately, and they would cull fairly well. The problem with that is it's tedious and hard to line up correctly. You may be able to use portals, but I am not sure if that would help for your application.

In reality you'll just have to wait until someone with more knowledge about performance decides to answer your question. My advice would be to get to work on something and get it working, however slow, and then address performance issues.

#12 DIF files do a number of rendering enhancements when on screen.

1. Only the visible faces are drawn. Any faces that cannot be seen are not drawn (saves rendering time)
2. They support Level Of Detail so that when an object is further away, a simpler version of it is drawn (saving time again)

To get the best performance will be quite a lot of work using DIFs. I'm not sure about the limit but I'm sure you'll hit it pretty soon doing that shape. If the shape is circular decide how many sections you can live with it will be pretty high I guess (about 100), then work out your angles on that and make 1 basic section. Then you need to make 4 version with less polys to be used as Level Of Detail (LOD).

Unfortunately for the LOD to work you'll have to assemble these pieces inside the world editor which will be very fiddly.

If you do not need to allow players to walk over these surfaces then you could do it as DTS shapes using the same techniques. Create your sections in Max/Blender/gamespace etc. Create 4 or 5 LODs and place them in the editor. This will give you a better quality, but the ball/players will bounce off the collsion mesh so you'll have to make sure you get that right.

#13 Ok. Before I decide on which way to go. Can anyone give me an idea of how difficult it would be to use terrain. Then I could weld multiple pieces of terrain together to form whatever shape I want. Where is the terrain info held, if I can access it through my code I can manipulate it to get it to do what I want it to do.

How do you initialize terrain? Is it possible to manipulate multiple terrains in one mission, and then move and manipulate one? If so, how will that effect the terrain editor?