[Verse-dev] geometry organisation

[Eskil Steenberg]

Hi

>
>This is mainly a question to exkil.
>I need some Information how do you think about the geometry structures in
>verse.
>Basicly we have a vertexlist, and a polygonlist that references the
>vertexlist. So far ok. But we don't have any information about what is a
>mesh and where does the next one start. That would really be important to
>know for any compression algorithm. Could i assume that one geometry node
>contains one mesh, or at least one polygon layer is one mesh? If not its
>really hard to figure out where a geometry starts and where it ends...! In
>Verse it's not really defined because you wanted an open system - thats good
>in most cases - but for that special one it is deadly.
>Maybe you could add some guide (or some kind of rules) in the spec how to
>create a mesh and how not. At the moment i have no idea how to solve this...
>maybe we can find a way at least within the uni-verse project.
>  
>
Im assuming that when you mean two meshes you mean two parts of geometry 
in the same node that are not connected.

Only the layer with id 1 should be used to reference nodes. no other.

So here is why there is no such support in verse. There are a number of 
additional things that people suggest that we should add to the geometry 
node the most common ones are:

-BSPTree
-OcTree
-Edge neighbor reference (my personal favorite! it would have made Loq 
easier!)
-Tri/Quad strips

Now they are all very use full. But the problem becomes keeping the 
structure intact.. If we would add any of thees we would have to require 
all clients that upload them to make sure they are properly stored. (in 
other words: if we add BSPTree every loader has to be able to generate a 
BSPTree). An other problem is that the server have to test the id the 
data is correct and that can take a lot of time.  And then obviously 
there is the problem that even the tiniest change can upset the data 
structure giving us a  bandwidth problem.

Here is an example i found in collada 
(https://collada.org/public_forum/welcome.php)

Collada is a interchangeable file format by sony that can store both 
polygons and strips.

Assuming that we write a 3d engine that favors strips, that uses collada 
files. We get the problem that even if the format supports strips we 
dont know if the applications that output it (say maya, max...) really 
generates strips.  And even if they do we dont know if the strips are 
any good. So the best thing to do is to take all the strips and polygons 
and put them together and generate strips in the engine. then and only 
then you have complete control of the strips.

So to me this solution is not very good because it makes the format 
bigger and gives people more work.

Any guide of suggestion in the spec on how to store the geometry would 
not be useful if the client could not trust that information.

If i understand your problem you could note that i have actually 
implemented a function in Loq Airou that select all connected polygons, 
its called "Fill selection" you can find my very simple solution in the 
Loq source. If you need it i can break it out for you.

E