Chicken, an Egg exporter for Blender 2.49 and lower

[lethe]

I’ll have to have a look - haven’t made the effort to fully understand the background exporter yet myself (!) - don’t have the time right this minute I’m afraid. I suspect you are missing something though, as it clearly worked in the past in the described way, and I doubt any real changes have been made since then - certainly not by me. I’ll get back to you once I’ve had time to have a look through though - will be latter today, noting that my day only just started. That part of the manual is unlikely to be entirely accurate though.

[astelix]

no don’t waste your time then - I asked you cos you’re on line and just if you can made a guess on-the-fly. I can easily put tests here and there to see if those values are truly read. I report you back later.

[astelix]

ok lethe, job done
you may grab my mods here. It is not a diff file but the whole chicken_exportR66.py - You’ll find all of my touches wrapped by … profusely commented so I guess you won’t find much difficulties to find and read them. For any Q just drop a line here. cya
EDIT
forgot to say: I noted a bug that if you export an animation (in interactive mode from GUI) with ‘single file’ on it won’t be played by pview. I’m almost sure it was a preexistent bug because console errors shows a try to load the animation as standalone file nonetheless, but judge from yourself.

[lethe]

Thank you, I’ll integrate that shortly. Not sure if i’ll bother with a release straight away though as you obviously have what you need and I don’t think anyone else is in a rush for it.

[astelix]

yes I’m ok now - FWIK nobody else require such a feature fixed so I guess there is no need to hurry.

[clcheung]

Hi lethe

If I parent the mesh to an armature, the corresponding subsurf modifier is no longer applied in the egg file. I have to click “apply” in subsurf modifier in order for chicken to export the model with subsurf. But then I can no longer change this modifier or reverse it.

Can you see if it can be easily fixed or there is workaround?

[lethe]

You can’t parent a mesh to an armature - it has to be applied as a modifier. Ignoring that on the assumption that is what you mean, in principal it shouldn’t be too hard as long as the API has an apply method, which I think it does - a simple three line loop should do it in fact as it already makes a copy of the mesh before exporting and accesses the modifiers to get the armature one.

Problem is a matter of weights - if applying the subsurface modifier doesn’t do something intelligent there (it would need to interpolate them), then there is nothing I can do, though I suspect it does do the right thing. Additionally, applying a subsurface modifier to an asset that is going into a computer game is probably the wrong approach. If you do have a use for it I can have a look though - as I said, it shouldn’t be too hard, and would apply for other modifiers as well, though very few modifiers actually make sense for computer game geometry.

[clcheung]

Yes, I mean apply.

[Shaba1]

clechung:

I think you are missing two very important things about Blender and the chicken export script

First:
I think chicken(I am not sure about this) only works to expert mesh type object and their parented armatures. If you applied subsurface to a mesh it is no longer a mesh. That is a mesh is a group of vertices described by the points in space, the vertices are then attached to each other by edges which are then used to build faces. The files for a mesh contain list of vertices. When you use subsurface in ANY 3d program it applies a mathmatical formula to the mesh data to smooth the vertices so that they object ‘looks’ more organic and real. The math is done in the memory of the computer and displayed on your screen as you use the software. The is no actual vertices saved in memory or on disk so there is not actual mesh. That is why you have to press SHIFT-ALT-C (IIRC) to turn a subsurface object back into an actual mesh object BEFORE export it with ANY of the blender export scripts i.e. colloda export,3ds export, .obj export or any of them export scripts. Everything you see when you subsurface and object is just math making it smooth not a ‘real’ mesh. That is why when you do turn the subsurfed object into a mesh object its had many times more vertices and faces the the intial mesh you started with.

[lethe]

Shaba1: Subsurface surfaces all work by taking a mesh, subdividing it following some rules, and then outputting a new mesh, then repeating till the mesh is fine grained enough to look smooth - his request is theoretically perfectly possible, the only potential barrier being blenders interface. Really, you should of realised this just by watching blenders subdivision surfaces as you adjust the subdivision levels…

[clcheung]

Shaba1, thank you for the explanations. But it seems chicken will export the subsurfed mesh and also smoothed mesh (by set smooth), isn’t it?

[Shaba1]

@clcheung

Shaba1, thank you for the explanations. But it seems chicken will export the subsurfed mesh and also smoothed mesh (by set smooth), isn’t it?

I seemed to be corrected on the subsurface issue. A smooted mesh should not be a proble at all since that just moves face angles out if they are less then a certain threshold.

[clcheung]

I must have misunderstood what you are referring to.

Here is what I mean:

1. Open blender, and use the default cube.

2. Export it. Now is the egg file is about 3k byte, of course it looks like a cube.

3. Set Smooth on. Export it. Now the egg file is about 4k. It still looks like a cube but the shading is a bit different.

4. Add a subsurf modifier. Set Solid. Export it.
   Now the egg file is about 11k. It looks like a smoothed cube.

5. Set Smooth on. Export it. Now the egg file is 14k.
   It seems no different from 4., but the shading is a bit darker.

6. Now add armature modifier. Export it.
   The file size is now 5k. It looks like a cube.

I would like to see the output of 6. looks like 4 (or 5 if smooth is on).

[lethe]

Ok, to explain what is going on…

Subdivision surfaces work by taking each face and subdividing it - for instance in the case of Catmull-Clark surfaces, as used by Blender and nearly everybody else, a quad (4 sided face) will become 4 quads, and a triangle will becomes 3 quads. The vertices of this new geometry then have there positions set using some simple equations in terms of the vertices of the original mesh. This process is repeated to obtain a smooth surface.

The smoothing option does nothing to the geometry however. A flat shaded face is just that - the surface is modelled at being its correct surface orientation, i.e. flat. A smooth face however has a distortion applied - whilst the face is actually still flat the surface orientation used to calculate lighting is blended across the face, and is effectively interpolated between faces to make them look smoother than they really are. The slight size difference between a smooth and not smooth mesh is because a smooth mesh stores the surface normal on a per vertex basis, whilst a flat shaded mesh stores a surface normal on a per face basis, and there are usually a lot more vertices than faces.

The size differences between these file are however, strictly speaking, unnecessary - Blender could recalculate all of this when you reload the file. However, to make loading fast Blender caches all of it in the file - storage is cheap, time is not.

[clcheung]

Thank you very much, lethe. It is very useful.

[clcheung]

hi lethe

I am looking in the chicken implementation.

I have some questions about how chicken collect the vertex information and write it out. I find that the blender Mesh object is used to collect the polygon (faces) and which in turn collect the vertexes information.

I use a cube as a test case. A cube has 8 vertexes and 6 faces. The current implementation will write out 24 vertexes and 6 faces.

My first question is, why not share the vertexes between faces ? Since we should know the vertex index from MVertex.

===
EDIT: I remove the second question. I may have made a mistake in the test.

[lethe]

Both of your questions have in fact been previously answered in this thread, though I’ll let you off as it is crazy large;-)

To c&p my previous response to the extra vertices:

That behaviour is due to the fact that Blender stores uv coordinates more efficiently than panda i.e. it can store a different uv for each face at any given vertex, so it can handle seems. Panda however only has one uv per vertex, so for it to replicate Blenders behaviour it has to duplicate vertices with different uvs. This may seem strange but it makes perfect sense - Panda is all about rendering stuff quickly and hence a simpler data structure is beneficial, whilst blender is all about editing, and so has to do it the complicated way.

In regards to your cube the default uv coordinates are such that all faces share the entire image, hence every vertex needs to be duplicated for all 3 faces that use it, making 24 vertices in total. If you take the cube and subdivide each face you will find that the vertices in the centre of the faces will now be shared between faces as they have the same uv values for multiple using faces.

After that post David (drwr) made the comment:

Also, note that duplicate vertices in the egg file are automatically collapsed together, when possible, when the egg file is loaded. The number of vertices in the egg file really has very little to do with the number of vertices in the Geom that is created from it.

And for the second question, yes, a transform is applied as the egg file format expects world-space coordinates, and my previous answer was:

…that is an inevitable consequence of using floating point maths. [for coordinates and transforms applied] Reality is that the slight error should not be visible to humans anyway, so its not really a problem. (Well, it can become an issue if tiling stuff as cracks can form momentarily, but then you should probably be stitching your tiles together for speed anyway, or if they are simple generating them in code.) You have to remember that once the egg file is loaded it goes through almost identical floating point transforms before it hits the screen anyway, so even if you did fix that problem for loading it would still re-emerge in panda.

[clcheung]

Thank you very much for the reply.

Yes, it is painful to search this post as it is too big and forum search can only go to topic level.

I am working on the shape key. I am able to dump the from the shape keys. But for the , do you have an idea how to get it or generate it ?

[lethe]

Nope - I haven’t had the time to look into shape keys at all really; just be warned that getting 'em to work will be fairly challenging. Also be warned that I am currently updating Chicken with a bunch of stuff, and I do like my diffs to be relative to the current version… I don’t know what your experience of repositories is but if you know what a rebase is do try and use it. (I can work around that, but the harder it is for me to integrate a patch the longer I’ll put off doing so.)

(Actually the forum search can work on the post level - its in the advanced options. That is how I found the relevant posts above.)

[ynjh_jo]

R66 failed to write the relative path correctly on Windows. The relTo is still in Win’s form.

BTW, this is mine, works on Linux too :

def getRelativePath(path,relTo):
    relTo = convertFileNameToPanda(relTo)
    prefix = os.path.commonprefix([path,os.path.dirname(relTo)])
    prefixLen = len(prefix)-(prefix[-1]=="/")
    return "." + ("/%s"%os.pardir)*(relTo[prefixLen:].count("/")-1) + path[prefixLen:]