Blender 2.5 to Panda not possible yet?

Planning for animation from the start – for sure. So as to be sure all the cards are on the table, the manual states eggs can contain:

A Model (static geometry)
An Actor (dynamic geometry)
An Animation (to be applied to an actor)
Both an Actor and an Animation

Is there anything else that could be missing from that list?

Alright, great. Lots of direction for me here. I guess at this point, it’s time for me to disappear and get started on the planning and experimentation (on the blender side). I’ll be back with more questions as I get into the details. Thanks so much for all the guidance!

Okay, I’ll have a look at 2.5 API

btw, chicken R93 ?

Ok, just had a look - R91 is the most recent release, R93 is what it is up to in the repository, so R93 is the absolute latest.

onelson:

That is more of a users view of an egg file - they are internally a lot more complicated than that. I would have a look through the list of classes in the Chicken exporter as it stands, but also check out http://panda3d.cvs.sourceforge.net/panda3d/panda/src/doc/eggSyntax.txt?view=markup, which is basically the actual spec. I would also get some egg files and read through them, including some that have been laid by the current version of Chicken.

To give some kind of overview an egg file starts with the coordinate system to use, then it has the materials and textures used throughout and then you have the object hierarchy, and finally the animations, which can be in a separate file (It is possible to have one skeleton shared by multiple meshes in separate files that have a common pool of animations - you will need to support that, though its not hard as your basically just appending the files for the single file export.).

The object hierarchy is precisely that - a hierarchy of objects, which can include empties, static meshes and animated meshes. Animated meshes come with a skeleton, which is then referenced by the associated animations.

Objects with geometry contain vertices and polygons, and if animated also contain joints to form the skeleton. The class will inevitably have an inheritance tree that has empty at the top, from which a static mesh inherits, from which an animated mesh inherits. Al 3 of these object types can be in a single egg file.

A vertex always includes its position, but typically has a surface normal and often tangents/binormals as well. A polygon indexes the vertices it uses, its textures and materials. Joints (Bones) give their matrix transform, in global coordinates, as all transforms are in an egg file (Watch out for that one - Blender will only give you back local transforms, so you will need to convert. I/the current Chicken source can help with that.) and the vertices that are members of the joint, with their weighting for vertices that are members of multiple joints.

An animation has some basic properties such as name and framerate but then gives the sequence of states for each bones transform.

I’m sure there is other stuff that I have forgotten - expect to write a lot of if statements!

Such is life (thought perhaps there’s another way through delegation). The egg spec is exactly what I needed. What a good read. Shame really. Any time I look at a format spec like this, I lament the fact “it could have all been expressed in json”. Heh.

More of a general question – is there ever a need in the production process to go from egg to blend? Do I need to worry about the round trip?

People often ask for this and the reason is obvious. Here on the community people use different 3d modelling packages and often only share the egg files, which is kind of universal format for us. This brings the problem, that egg files you get from others are hard to modify. You can try to convert the egg to x and import that one in blender, but usually it ends up in a mess.
That said, a way of importing eggs into blender would be great, but I suggest you don’t mix it with the chicken exporter.

I have been living without a two way translator forever with panda and can keep doing so but it sure would be nice.

I would say do the blender -> Egg first and then if you still have the time and desire do the egg to blender bit.

BTW thanks for doing this!!

Douglas AKA Human-bean and magick-raven or even magick.crow :slight_smile:

Someone above threw in JSON.
Speaking about file formats, is there an egg parser around, which is not part of Panda (or at least is independent of other panda parts)? I agree with lethe that the exporter should run independent of Panda, but for that we’d need an external parser library/module.

blender -> collada -> egg -> panda idea:

How similar or how different is the egg format from collada?
Could we work around the whole issue with the egg exporter using a collada exporter in blender and converting that collada file into egg? I know it sounds like more of a work, but we can go sure that blender’s collada export will be further developed and maintained for sure. And on the other side we don’t know how much time it will take till Panda’s collada importer is ready.

Collada has two problems. The Blender exporter does not work AND the Panda side does not work. Shoving it all through Collada would just bring us back to our first problems and make the system reliant on Collada. (Note, does not work is likely overstated but you get the idea.)

Having the ability to check with Chicken if my models looks good in panda previewer has in the past saved me a LOT of time! I hope when you say that you are taking Panda out of the exporter, you are not talking about removing this feature.

I have used this feature to make sure I had the right model, to see if the model faced the correct way and to see if the colors were working.

DEK

The ‘blender -> collada -> egg -> panda’ route already exists, and does in fact work for static geometry - it just does not support animation or advanced materials right now, making it useless in the real world.

By removing Pandas dependency what I mean is Chicken will run without Panda, but have features that only work if Panda is available, unlike now where it won’t run without Panda, but the vast majority of exports do not require it to use Panda at all.

With regards to importing egg into Blender I agree with everybody else - export is the important one, and to be honest I wouldn’t bother with import myself - that is just not the purpose of the egg file format.

Another thing that I thought off - be careful with materials and textures - due to the differences between Blender and Panda you will often find cases where the same material or texture is applied to multiple objects in Blender, but for Panda you have to have multiple versions of the same object due to setting differences that are pushed into a material/texture in Panda but kept separate in Blender. This involves some automatic renaming - you might want to copy what Chicken currently does, or do something different.

Making the exporter Panda independent doesn’t mean it can’t use Panda. I’d only be happy if the core functionality works as standalone and all those additional features give a warning on missing panda.

I see what you’re saying about the panda dependency. I’d love for it to not be optional as ultimately I hoped to embed some kind of in-engine panel for model/animation/material preview. This goes along with my desire to build this up so that there can be level editing and preview happening in blender similar to what they do with BGE. This is all distant future stuff of course. Fact of the matter is, there’s no point in making something a dependency until it’s required to make the thing “go”.

I’ll do what I can to ensure it isn’t a requirement for as long as I can. In fact, all that other stuff can probably be an entirely separate project that itself depends on the egg export system.

I’m also, like everybody else, against rushing the import part. Would be nice, but it’s the exporter we really need and it should get all the focus.

I wanted to ask whether relying on Panda could make it easier to develop the exporter (like, with the use of EggData), but then it came to me that Blender uses Python 3, while Panda is written for Python 2. That, AFAIK, makes it impossible to use Panda’s stuff in a Blender script, right? It probably also makes wysiwyg embedded previews, that onelson mentioned, impossible too?

Mmm, I don’t remember mentioning wysiwyg :> For the preview stuff I had been planning on building external apps that blender would push data to. With that in mind, you’d still need panda installed unless I go crazy with py2app/exe.

Everyone agrees: first thing is egg export.
After that, who knows? We’ll see.

>>> import direct.directbase.DirectStart
Traceback (most recent call last):
  File "<blender_console>", line 1, in <module>
  File "/usr/share/panda3d/direct/directbase/DirectStart.py", line 1
    print 'DirectStart: Starting the game.'
                                          ^
SyntaxError: invalid syntax

Quite right. importing from panda will not be possible until some porting action has been taken, but again, there shouldn’t be a need to do this just yet.

Looks like, in theory, an egg importer/parser could be achieved by writing a custom ctypes wrapper for the Egg* C++ api. That or just wait long enough for the whole world to be on py3k.

Blender is being bleeding edge when it comes to Python. They are currently using 3.2 which is a royal pain for me because my 10.10 Kubuntu does not have it yet thus as of the change I can no longer run SVN without doing a bunch of Python work in Kubuntu.

Panda (and I may be quite out of date here) is doing the exact opposite. They are not doing any Python 3 at all, last I heard. My understanding was that they would wait until the last minute to change.

So please don’t make plans for them to come together because we will just end up waiting and waiting just as we have done for Chicken for 2.5 Blender. Sticking with just passing data will keep it all working in the long and short term as far as I can see.

For the record, you wouldn’t need to import DirectStart (or any of Panda’s Python modules) to use the Egg* interface. But yeah, Python major versions aren’t binary compatible with each other, so it won’t work anyway.

ctypes might be an option, yeah.

Also for the record, this is not a Python 3 vs Python 2 thing. Even if Blender used Python 2.7, while Panda builds might be compiled against a different version (like 2.6 or so), it still won’t work.

I ran 2to3 on the panda3d package and actually almost all of the stuff to change is simple syntax stuff. range instead of xrange, print() instead of print, the syntax for raising exceptions, yadayada.

Bad news is, those refactors are needed throughout the entire package, including the pandac stuff. Eh, regardless, I have enough to work on with the egg spec. I’ve started sketching out how the code will work and how the classes will interact.
I’ll leave the distant future scoped stuff alone until a more practical time.

Just be clear here - Chicken does not use any of Panda for the export process - an egg file is just a text file, and it just writes the relevant text using standard file i/o. The only interaction between Chicken and Panda is in running the tools, such as pview, after it has done the actual export. Right now it requires Panda be available, even if your not running pview etc. - that is what I am saying is an issue. All of this talk about converting python and interfacing with Panda is irrelevant, as the Chicken/Panda interface is done entirely by Chicken running python tools on the command line. For an importer access to the egg tools might be useful, but for export doing it yourself is almost certainly the easier option.

One more hint hat just came to mind:
Current Chicken behaviour to handle modifiers is to clone the objects, edit the clones (i.e. apply the modifiers.), export the clones and then delete them - only real way to do it, and I presume that that same will be required in 2.5, or some variant thereof.

The only reason I was looking at ways to embed panda: those distant “pie in the sky” features I’ve been talking about. Wanted to get a sense of the feasibility.

Taking egg imports out of the equation, you’re right - the whole situation is shaping up to be an excellent exercise in loose coupling. Everything I need is in that egg spec.

In my research, I came across something that didn’t fit neatly. Your mention of “clones” reminded me.
What’s the high-level view of how chicken dealt with instancing? Did it leave that entirely to panda (ie, you build the source geo, export the egg then handle all instancing in the panda api), or did you consider converting blender instances into panda instances?