Gerbil
Green Marine
Posts: 34
Registered: 06-01 |
Why break everything into triangles at all?
Err because that's how every single consumer graphics card in the world works? Basically all games feed a stream of triangles to the gfx card CPU which renders them. Even things like variable level meshes are eventually broken down into triangles. There's a variety of reasons for only using triangles, of which the main ones are:
- Any shape can be broken down into just triangles
- A triangle is always flat by definition
- It simplifies what a gfx card has to do
IE once a card processes triangles as fast as possible, it never needs to do anything else. Building in flexibility (eg curves, quads etc.) slows it down. They don't want to do this :)
Some cards go so far as to not have a line primitive - they simply draw a very thin triangle.
Also, take a look at things like nurbs and arbitrary shaped polygons in GLU and GLUT - they are basically another method of converting shapes down to triangles.
You may not have to be aware of this, but ultimately all models everywhere are drawn as triangles. Sometimes building this into your code can help a great deal.
With current, industry standard (Voodoo3) video cards, you've got 16 megs of RAM to play with, and 120 mhz of pixel pushing power (not much, but I like superlatives).
On board RAM only affects viewport and texture sizes / quantity, they are nothing to do with the actual rendering of models.
A triangle may be the smallest and easiest polygon to render, but it just seems like a pain to me to have to break everything down to triangles anyway.
See above. You may not realise it, but at some point everything becomes triangles before rendering. I start with triangles because then there's no processor overhead of converting other shapes to triangles on the fly.
but why take a rectangular wall with nothing near it and break it down as well? Seems like a waste of cycles to me.
NOT doing it as triangles will be slower, you'll have to trust me on this one :)
As to the level format, I haven't decided yet. I don't like the idea of using WADS, because they contain a lot of info about the sprites in the level, and I don't want to use any sprites at all, if I can help it.
I agree, but they don't have to translate to sprites. I'm simply using it as 'object' data, and hopefully will replace sprites with proper 3D models. Just because Doom says an object is a sprite, doesn't mean we have to code it the same - that's the joy of what we are doing. By not sticking slavishly to Doom's model we can improve upon it :)
On top of that, DOOM levels were never built to have the floors and ceilings looked at. They were built 2 and a half D, which I'm trying to correct. That means that the levels need to be rebuilt. If I do write a level editor, it won't be until after I'm done with the engine itself.
This is my biggest problem as well - making the floors and ceilings interesting. Not having got any of the newer ports with sloping floors I'm not sure how editors work for doing slopes. Personally I'll be supporting them in a limited 'I can do them, but no-one else can' way, which is a pain, but means people will be able to create levels that run in my program, and leaves me with that little bit extra to look good (after all, I'm hoping to make money from all this, even if I do give out everything to fans for free :).
Anyway, just keep us all posted with updates :)
|
!logo.gif)
06-18-01 16:05 
