|
Author
|
Topic: Quads or Triangles (MAX2OBJ Export)???
|
Laika 801
Pilot
|
posted 01-31- 11:59 AM
   
I´ve read the manual for my 3D card again (TNT2) especially the descrition of the "3d pipeline" It looks like this:Object data
..
Tesselation
..
Geometrical transformation
..
Rendering
..
Display on the monitor thats it. Tesselation = "...the object is broken down into a number of triangles. The vertices of the triangles are described by coordinate points (x,y and z)...". So does it make sense to convert triangles to quads (For me it seems that quads would be more work for the 3D Card = slower gameplay - but I´m not an expert in this) ??? LK801 IP: Logged |
Tailslide
Pilot
|
posted 01-31- 12:59 PM
I have a TNT2 and I get faster FPS with my plane exported as quads than when I export as triangles. TS
IP: Logged |
Whirlwind
Pilot
|
posted 01-31- 01:01 PM
According to a simular response to a simular question, the fewer polygons, the better was basically what MH stated. SDOE has a polygon based pipeline.IP: Logged |
Laika 801
Pilot
|
posted 01-31- 01:37 PM
...in the manual they define a polygone as a triangle......so isn´t the question : could the card handle quads (Y/N) and if not - what takes longer, the work for 2 triangles or 1 quad...
Maybe this is all crap  Whirlwind - do you remember in wich topic MH says something about this (Maybe the definition of an (SDOE) polygon)?
IP: Logged |
JT
Pilot
|
posted 01-31- 01:54 PM
By definition, a polygon is simply a flat shape. TS and Whirl are correct. Using quads means a lower polygon count, which is good for SDOE. It also means fewer vertices... I don't know if that matters.IP: Logged |
Bryan Russell
Pilot
|
posted 01-31- 05:47 PM
Triangles are the native format for most 3D cards at the lowest level, and if all SDOE did with the polygons was draw them then it wouldn't matter if they were tri's or poly's. In fact it would probably help if they were tri's (save the the conversion step).OpenPlane also checks every poly for other things, the one that springs to mind is collision detection. If you have a model 100 triangles, it will take 100 iterations to do collision checking, if these triangles are converted to 50 quads then the time is halfed. Obviously the more tri's per poly, (or ultimatly the less polys) the better. This is really significant when you have ten of thousands of polygons in a scene, and since mostly the collision detection is probably excluding most polys from being hit due to rather simple calcs it doesn't matter whether the polygon is big or small. JT the verts should be the same for a given triangle mesh converted to quads or polys. Bryan IP: Logged |
JT
Pilot
|
posted 01-31- 11:08 PM
>This is really significant when you have ten of thousands of polygons in a scene, and since mostly the collision detection is probably excluding most polys from being hit due to rather simple calcs it doesn't matter whether the polygon is big or small.Is collision detection something that the game checks for within a cycle or is it more something that is triggered? >JT the verts should be the same for a given triangle mesh converted to quads or polys. Really? I thought a quad only needed four verts whereas two tris would need 6? A quad needs 6 verts? IP: Logged |
Laika 801
Pilot
|
posted 02-01- 06:03 AM
thanks bryan - I dint think abou this aspect... IP: Logged |
Laika 801
Pilot
|
posted 02-01- 01:30 PM
3ds Dos didnt work with quads ;\IP: Logged |
Bryan Russell
Pilot
|
posted 02-01- 03:26 PM
Actually you are right in terms of SDOE in that it doesn't share verts, my mind was more on the norm, where a triangle strip would share verts. I've often wondered if SDOE actually optimises verts in loading. Since each vert needs to be transformed for each frame, having twice the verts would mean half the performance (transformation wise anyway). I can't see any reason why they wouldn't. I'm sure collision detection probably triggers something along the track but in the first instance you still need to do a check to relise you need to trigger something. From what I've seen it apears to be model limited i.e. the more model records you have the bigger the hit to FPS. Probably theres a base check on each model record to see if it has any possibility of being hit, and if so it checks its polys. This is one reason model count should be kept as low as possible and also that use of the obNoCollide property is probably usefull were appropriatte. IP: Logged |
JT
Pilot
|
posted 02-01- 03:32 PM
So, why is collision detection done on each poly? Wouldn't it have been much more efficient to use a system of bounding boxes to detect collisions rather than having it keep track of every poly in the highest LOD?I mean, considering that the wing is actually four objects (inner wing, outer wing, flap, aileron), does it really matter where the bullet hits any of those objects? Wouldn't it have been better to represent those parts with bounding boxes? [This message has been edited by JT (edited 02-01-2000).] IP: Logged |
Falck
Pilot
|
posted 02-01- 04:21 PM
Well that depends on how close you get your bounding box to the actual lod. I always hated games where the bounding box didnt match the shape.Speaking of poly's, how hard would it be to code the game engine such that when a part explodes it breaks into its different polys. Maybe not a separation for each poly, but at least random cracks in a lod breaking it into 5 - 10 parts. That would add a lot to the visuals IMO IP: Logged |
JT
Pilot
|
posted 02-01- 06:55 PM
I agree, Falck... but what I mean by bounding boxes is to have, for each plane part, an invisible, simplified mesh that keeps track of damage. In other words, modeled bounding boxes, instead of simple rectangular bounding boxes. Not only would this improve framerate when there are lot's of planes in the air, but it would also improve the online situation... woudln't it? [This message has been edited by JT (edited 02-01-2000).] IP: Logged |
JT
Pilot
|
posted 02-01- 07:06 PM
One more question... if a plane has a cockpit .sm file, does the game check for hits on that? If not, it seems to me we could greatly improve framerates, especially where bombers are concerned, by giving all the planes separate cockpit .sm files. I mean... yikes... is the game really checking the bombers inside and out for collisions?
IP: Logged |
Falck
Pilot
|
posted 02-01- 07:06 PM
How many less polys would make up the bounding box than make up the lod? I mean, in a sense the lod is itself the bounding box. At least thats how I understand itIP: Logged |
JT
Pilot
|
posted 02-01- 08:52 PM
Not many... perhaps 50 polys for a fuselage shape? You could draw a very accurate hit box with that amount, don't you think? Wings could be handled as flat panels, so those would be drastically reduced. Also, I'm not thinking so much in terms of just one plane, but the exponential effect when many planes are in the air. IP: Logged |
Falck
Pilot
|
posted 02-01- 09:32 PM
Probably true 
But not 'flat' panels for the wings
theres nothing worse than getting behind someone and not being able to put rounds into their wings. IP: Logged |
Bryan Russell
Pilot
|
posted 02-01- 11:21 PM
The file refs just get melded into the whole object when its loaded so yes it would check the cockpit.sm. However as I mentioned before there is a obNoCollide property that I would guess from the name would turn off collision detection for a model/lod. So for cockpits and interiors, assuming I'm right, the use of the obNoCollide thing would be a big plus.I'm only assuming that its a per polygon collision detection because that's what was stated earlier on by someone from Parsoft. Its definitly per model/lod, so you should 'turn off" collision detection for the inside walls of the B17 for example. One of the great things about SDOE/openPlane and the thing that makes it so flexible, is the fact that every things designed to handle generic application of the OpenPlane concepts. So one of the advantages of per polygon hit detection is that you could have ,for example, a object like a tube that would have bullets pass through the centre, where as a per LOD bounding box would show hits in the hole.
IP: Logged |
JT
Pilot
|
posted 02-01- 11:41 PM
Thanks, Bryan... that is some very useful info! I'm glad there is a way to designate what parts the game should skip over when checking for collisions.
IP: Logged |
Laika 801
Pilot
|
posted 02-02- 07:29 AM
Laika here, "Its definitly per model/lod, so you should 'turn off" collision detection for the inside walls of the B17 for example." So the cabin/inside walls of my fuselage should be an extra object ???(if so I had remodel some things )
IP: Logged |
FSIC Messageboard
UBBFriend: Email This Page to Someone! 
