Quote:Original post by adder_noir
I will probably finished this exercise purely for academic reasons.

Doing this for learning is an excellent reason. If you don't feel time pressure to get this stuff done and to move on to other things, go for it!

I'm not saying the code you write will be useless the day after, in fact you'll find that when you need to write a geometry re-indexer or a vertex cache optimizer, you'll be able to reuse a lot of the constructs here. Adjacency information is required for a lot of geometry-related tasks as well, for example in navigation mesh pathfinding.

Quote:Original post by teutonicus

Quote:Original post by clb
(a sign of a good tool is when you can always blame the artists ;)

OT: Quote of the day =)

:D

Hi!

Ok thanks I read that, very humourous in places!!!! Hahahah you obviously have alot of experience in the field ;oD

I'm still having hell getting blender to export this stuff. It will show smooth in the program but the script is powerless to do anything with it. Even the internal console in blender doesn't shift it. It only responds to the setsmooth command in the environment menu, never directly from python and it also doesn;t export what it shows in the environment window!!

Just one last question before I start using your code to get stuff happening here (good template btw thanks a bundle). How do I acquire the adjacency data? I'm au fait on the other stuff I've written my own ccross product functions before and stuff. Only the adjacency stuf bugs me. So far my export writes an indexed list (with duplicated indices many times over), vertex list and some crappy normals that make the model blocky and look like calculus going the wrong way.

Can I acquire everything I need from this? Sounds really good this is what I'll be working on now, even if just for the hell of it! Thanks so much ;o)

Quote:Original post by adder_noir
Ok thanks I read that, very humourous in places!!!! Hahahah you obviously have alot of experience in the field ;oD

I'm still having hell getting blender to export this stuff. It will show smooth in the program but the script is powerless to do anything with it. Even the internal console in blender doesn't shift it. It only responds to the setsmooth command in the environment menu, never directly from python and it also doesn;t export what it shows in the environment window!!

Thanks! If you can post a screenshot of the good and bad cases, I'm sure someone can see about the issue in more detail.

Quote:Original post by adder_noir
Just one last question before I start using your code to get stuff happening here (good template btw thanks a bundle). How do I acquire the adjacency data?
I'm au fait on the other stuff I've written my own ccross product functions before and stuff. Only the adjacency stuf bugs me. So far my export writes an indexed list (with duplicated indices many times over), vertex list and some crappy normals that make the model blocky and look like calculus going the wrong way.

Can I acquire everything I need from this? Sounds really good this is what I'll be working on now, even if just for the hell of it! Thanks so much ;o)

You're very welcome. Adjacency data comes in several flavors (people give different namings for it, but the conventions never seem to be the same), and it serves to be able to answer the following commonly asked questions:

1. Given a triangle, what are its neighboring triangles? (are there T-junctions for this triangle?)
   
2. Given a position of a vertex, which triangles have a corner at this vertex position?
   
3. Given a position of a vertex, which vertex positions are reachable from this vertex just by traversing a single edge in the mesh?
   
4. Given an edge (a pair of vertices), which triangles share their edges with this edge?
   
5. Given a vertex (by its index in the vertex buffer or by position), which other vertices (by their indices in the vertex buffer) lie at the same position?
   
6. etc, whatever you can think of.
   

You can think of this data to be a lookup table to accelerate these kinds of queries, since technically you wouldn't need to calculate this data and you could just compute the information on-the-fly by looping through the geometry, but generating this lookup table improves your performance by a factor (or two, in some cases) of n (# tris or vertices), i.e. it's the sane thing to do.

Now in your case, you're doing queries of the form #2 and possibly #5. The first foreach loop in the pseudo-code in my above post shows how to compute #2. If you want to re-do smooth/hard edge division, you'll need to recreate the per-vertex data and re-index the mesh, for which you'll need #5. This is often done by just converting the indiced geometry to an unindiced triangle list, then doing the computations, and then converting back to indiced geometry.

So, in effect, there's not really any magic to generating adjacency data, you just loop through the primitives you're interested in (triangles, vertices) and store into a lookup table the interesting information you want for each of those primitives. Then when processing, you have that data in a neat table to help the actual work.

That's great! Thanks. I think from what you write I can acquire the different triangles a given vertex belongs to from the handy index list my export script puts out. I think I'm going to have to ditch the normals that come with it though and make my own from scratch. I've been trying some halfway house method that didn't get much results, just some very odd behaviour.

Time to do it from the ground up I think. I'm going to use your template and some well planned code on a simple cube to try and get this to work. Seems all I have to do is acquire the normals with the cross product (I might be able to skip this bit using the normals outputted from blender) and then average them all in a mean fashion.

I kind of tried this last run though so I'm not too sure how I'll fair better this time, but for damn sure I'm going to try it. I'll try and get a screen shot of the blender 3D view and show it to you, but tbh there's not much to see. Just a smoothed cube which renders solid in DirectX.

I've got something to do this morning I'll be back onto this later today. thanks ;o)

**Edit** Dumba** question time:

I don't have to do this on the fly do I? I was under the impression I can just re-calc the fixed normals for the model and then load it and it will always look smooth. That's right isn't it? As the normals don't change at all at run-time do they?

Quote:Original post by adder_noir
I don't have to do this on the fly do I? I was under the impression I can just re-calc the fixed normals for the model and then load it and it will always look smooth. That's right isn't it? As the normals don't change at all at run-time do they?

You're right. The normals in the input vertex data do not need to change, unless you change the position data in the input vertex buffer. When you're rendering the object in the world, remember to transform the normals in the vertex shader properly (remember the inverse transpose if you use non-uniform scaling, otherwise the usual object world transform matrix suffices for normals as well).

http://img267.imageshack.us/img267/9581/horridpic.jpg

^^^ Have you ever seen anything so horrid? Nope thought not :oD I'm probably gonna leave this one as I'm not getting on too well with it, but hey it's been a great ride and I wrote at least some code that did *something*. I'll either quest for a blender fix or just live with blocky models and shape them better in blender.

Thanks so much clb this was probably the most interesting thing I'll do for ages cheers ;o)

Just one very last question - I assume (now anyway) that every vertex normal is unique here? There are no vertex normals shared between vertices. For example the results above are trying to apply 1 averaged normal to all three normals in the face thus causing utterly buggered results.

SO just to set me straight for my last bout of self-discovery - every vertex normal even those within a given face are all different right? There's no faces where all the vertex normals are the same for all 3 verts that make the face? Sorry to be such a pain in the a$$ but well you got me interested ;o)

I won't ask anymore tho I promise - time for my own work or lack of it to commence ;oD

I'm confused. Doesn't Blender actually store the normals for each model? Can't you just export them in the export script? Looking in the .obj or other export scripts should help find the right things to export.

Why not just hit the "smooth" button ("Links and Materials" tab under the editing panel (F9) in 2.49, left side panel in 2.5 alpha) either in object mode to smooth the whole model, or in edit mode with the verts / faces you specifically want smoothed selected, which will weld the relevant vertices. If you're trying to auto-smooth normals, Blender can do this too, with a set angle constraint.

Your model looks to be flat shaded in that picture, i.e. every vertex on a particular face has the same normal, and if a vertex is shared between two or more faces, the vertex will have a different normal for each face that shares it. It sounds like you want smooth vertex normals, where each vertex has only one normal, which is an average of the normals of each face to which the vertex is connected. Sorry if you already know some of this...

Hi sprite.

That's exactly the problem. They will show in blender but they won't export. The 3D view in blender is also unresponsive to commands from the python console too when given smoothing instructions. The only thing that makes it smooth is the menu button set smooth but none of that normal data comes out with the model after export. Bugger :oP