Topic awaiting preservation: Polys / Vertex ratio (Page 1 of 1)

Can't get my head round this one. Say I have a mesh, generated programatically: It is a torus, and it seems to have
the same amount of vertices... and quads. Which is confusing, given the fact that a quad is made of four vertices.
I am trying to get the smallest possible amount of vertices and polygons, but the more I dig into this issue, the more I stumble in this ratio issue.

It seems to me that "one quad, four vertices" is NOT a rule of thumb at all and that the amount of polys depends on the way vertices are connected, but...
What is odd is that the primitives I generate are geometrically perfect, work well, have perfect normals and texture coordinates, but while I clearly
"view" the process of generating the solids in question, I can't understand how the vertex/poly ratio works, or if there is a linear formular to determine one depending on the other.

one word : TOPOLOGY

In topology you only care about the number of holes in a shape. There's a simple formula to get the Euler characteristic ( X = polyCount+vertexCount-edgeCount ) to get the genus of closed shape you have. ( e.g: a sphere or a torus, or a 2-torus, or a 3-torus ... )

Hope that helps,

Well, it does actually, I didn't know topology went as far as that. Anyway, I am now trusting my own "feeling", and obviously doing something right.
Thank you, poi.

Btw, it's a wip, but here are some screencaps. I've just implemented per-vertex normals for my 3ds models.
Have a lot to do before making a final though...

Features: dual paraboloid (view independent) environment mapping (homebrewed), and some post processing filters like radial and twirly blurs, and
a shitty cartoon shader.

It chokes on some .3ds files for no reason that I can think of.
And the object model, for once in my lifetime, is extremely detailed, with correct encapsulation and objects / methods for every important thing.
(namely, a scene object is an objects stack, very handy to load/unload worlds/scenes/rooms/whatever at runtime)

Anyway,

Diablo with dual paraboloid environment mapping (3ds model)


Radial blur


Hand made primitives, solids of revolution (no gluttorus or glutsphere involved)


(Edited by _Mauro on 12-28-2005 00:18)

Regarding the torus: every quad touches four vertices, and every vertex touches four quads. If you pair each quad up with the vertex at, say, it's upper-right corner, you'll see that they pair up equally throughout the entire torus.

Slime, what you mention here means that the torus has the same amount of vertices and quads, and was what originally led me to post.
For revolution solids, I have two others, cylinders and spheres namely, and am trying to generalize the generation of such solids (in order to be able
to pass a 2d "path" to a 3d revolver function and get a volume out of it).

The tricky bit is that 2d paths passed to such a function can lead to different topologies, and I am storing the polygons/vertices to arrays, not dynamic data structures
like linked lists, so I need to know how many vertices and polys I'll generate.

Anyway. I am starting to love c++, and I'd better get to love it deeply, I have 4 huge assignments of this kind for the end of january
(a simple MS SQL interface, an AI project - ants I guess, and a UML project where the decomposition and diagrams have to be really elaborate).

Oh, and since I have a stable build of the above thing ready, let me sort the 3d models and bitmap files, and I'll upload.

Ok, I've resized the screencaps to a reasonable size, and here is the current stable build:
opengl project - 1.8MB zip (includes glut32.dll, needed to run the program)

The executable has been shrunken down to 118KB.
Anyway, it has the following features:
- display of several scenes in points only, wireframe, solids, solids with textures (if texture coordinates are available), environment maps (view dependent or independent)
- post processing filters such as radial and twirly blurs
- 3ds files loader

It has bugs, nothing big, namely the sphere/cylinder generation issues.
It shouldn't eat up memory, it does use display lists for each object, as a stack, but there is a maximum of 4-5 objects in any given scene, so..

It runs fairly well on most recent and some past gpus. Actually, any hardware from 2000 should be able to run this one.
What else? For coders, I have used the following libraries:
- glut, of course
- glui for glut-based interfaces - http://www.cs.unc.edu/~rademach/glui/
- glpng for png loading to textures - png alpha is heavilly used in the dual parabolloid mirror effect - http://www.wyatt100.freeserve.co.uk/download.htm
- 3ds loader tutorial - http://www.xbdev.net/3dformats/3ds/3ds.php

And dev cpp. The above libraries almost all come with a dev cpp devpak, with the exception of glpng, I had to compile that one myself.
The rest is pretty self-explanatory.

that ogl project crashes upon execution.

Should not, have tested it on 5-6 workstations already, some latops, some desktops.
Maybe some missing data in the package, or the fact I've realigned it a bit wildly to compress it to 118kbs?
Grumble, assuming you are serious (stuff happens, some of the best demos need a final to allow them to run on all systems), would you kindly give me details about the
configuration in use?
Windows version, RAM, and gpu?

Ok, I have two things for you.
One is the same xecutable, without all the packing.
http://www.beyondwonderland.com/data/C++/stable_build_unpacked.zip

The other are usage tips:
1) When you unpack these files, does the "data" folder reside besides the "exe" file? It should (pretty obvious I know)
2) Same for glut32.dll, ideally.

And I'll test it even more, but 1/7 being a small failure ratio, I need the maximum information to be able to correct this issue.

Shite, don't even spend the time, I've reproduce the bug with packed and unpacked versions on a couple of machines.
Will let you know when the unstable build gets stable again.

still crashes.

also it seems my VS2005 debugger cant open it, so i cant tell you where i crashes. :/

Yeah I know, thank you anyway. It seems to be related to the scene/objects stack, and my poor array based implementation.
For some reason, it still works like a charm on my system.. go figure.

It can be the objects stack, or the sphere/cylinder generation: too many vertices, or polys, (but then it would crash on my system as well), or problems with object allocation on the stack.
When I get some time again (sigh), I'll try a linked list version, or something of that kind.

http://www.beyondwonderland.com/data/C++/hotfixed_0.1.zip

Ok, I've narrowed down the number of issues.

{!--
The quick tech note: as I said, I am using a stack of 3d objects, now as a linked list. Each object is made of polygons. Each polygon is made of texture coordinates and vertices, a variable amount of vertices.
And 3d objects are compiled to opengl display lists at runtime, so I have different types of memory allocation/deallocation.
So, the nasty access violation raised by the previous version at startup has two main causes: a problem in the objects stack, and a nasty "synchronisation" problem,
with the display loop trying to access polygons that were in the course of being destroyed.
--}

As these have been fixed, you should now be able to double click/run it. Please let me know.

Now, there still are two main bugs to fix /!\:
- primitives generation, bugs out and even crashes for some values for the slices/stacks sliders.
- a memory leak. I know the cause (tex coordinates can't be deleted for some reason) at least.

That's it for now. As I know where the next bugs reside, my next task will be to fix them and make the product 99.999% stable.
Oh, with the above version, there is some debugging info available when running it from command line, spheroidz >log.txt



Please, please, download the exe above and let me know if it starts normally on your machine.

nope, still crahses.
it seems you are writing to a block of memory, which you havent allocated before.

It's weird, every new statement has it's corresponding delete except the polygon thing I mentionned.
Plus I've stress tested the application using various tools, including Windows debugging tools by Microsoft, in addition to the Visual studio debugger.
Plus it works on my machine.
A cooky for you for taking the time to test, I have to check this on another machine, or try to compile it on a Linux, or something.