Yup, sure - its thaines@gmail.com. I’ll integrate that, and wait for the test file and stick it in the test subdirectory in svn. (And then commit it back to sourceforge.)
Ok, I’m going to post this as a separate message as its intended for users of Chicken in general -
What should the default behaviour for Chicken be? - one file containing mesh and animations or (current default) one file for mesh then a file for each animation.
Both modes work and it currently defaults to many files, however, loading a single file is obviously easier (e.g. = Actor.Actor(‘my-file’) then the animations are as named in the exporter.), which is preferable for newbies so I’m thinking of making that the default. But then the multiple file method is what everybody is used to. So, what do people think?
lethe: If no one has done so already. I just want to thank you for taking up chicken. I means a lot to me as a blender user.
Is there anyway you can publish a list of new additions that you have made since R44?
Thanks:-)
As for the improvement list you can get it from the forum posts, however, I intend to sit down and update the manual at some point, and it has a revision log in, so I’ll update that when I get there. For now however I’ve pasted it all in below:
***R51:
-
The use of tangent maps now works by using Blenders tangents/bi-normals directly. The GUI allows you to disable this feature but its enabled it by default as you would be mad not to use it.
-
Mweb’s single file patch has been integrated, with an interface so its use is optional. This allows a single file to contain a model and all its animations, making loading it simpler. Defaults to off as most people are used to multiple files.
-
Animation details are now saved into an object property when you hit the export button and reloaded when you next run the script. This means that you don’t have to re-enter the time ranges, fps and names for your animations each time you reopen the file.
-
Package creation script works under windows.
***R52:
- Spaces are now allowed in names - in principal for everything, not just objects. (Haven’t tested everything, but objects, materials and textures all work fine.)
- Changed sub-group for multi-material objects naming scheme. Instead of [object name][index] its now [object name][index][material name]. [index] is formatted to always be two digits, i.e. 00, 01, 02 etc. I returned it to being zero based too, as programmers will be the once interfacing with this.
- Similar to above for texture names. They are now called [material name][index][texture name]. Index is again always 2 characters.
- Enabled curve support by default. Put in a warning if you use an unsupported curve type. (Must be NURBS and can’t loop.)
- Made 2 spaces the standard indentation for the main script, cleaned up indentation where screwy.
Below as provided by zuck:
- Fixed bug for meshes with armatures but no animations entered.
- Support for mip-mapping setting in blender - will copy from blenders texture options.
- Dupligroup emptys are now replaced by file references. To decide the filename it goes down a set of checks and uses the first that works - first it checks all objects in the group, if any have a ‘filename’ property (From the game engine tab) that is used, after conversion from being a blender style filename. Second it checks to see if the group is in an external library - if so it uses the filename of the external library without the .blend. Finally, if both of the previous fail it simply uses the groups name.
Below as suggested by pro-rsoft:
- Any uv texture called UVTex will be given an empty name, to make it the default texture stage.
***In the repository, not yet released:
- Extend/clamp/repeat texture attribute support. (Provided by Zuck.)
Uhm…I think there is a problem with tangent map after r52: if I deselect “tangent/bi-normal” option, no normal mapping effect appears in pview (with L and P pressed). If i push “tangetn/bi-normal” button, no texture appears at all… 
What’s the correct setup of Chicken options for normal mapping?
Just tested it - its working fine for me. (In doing so I extended the test case in case I was missing something - the newer test is now in subversion.)
It should work with that button pressed or not - that only affects how it calculates the tangents/bi-normals, with it being pressed being prefered. If you want an example of how to set it up I’ld go look at the tests/export-normal-test.blend file, as it demonstrates it nicely. Not sure what is happening to be honest - if it was working for you with a R51 then nothing in that code has changed with R52, and if it was working with R44 then having the button not pressed is identical to that.
If you still can’t figure out and its ok to send the blender file my way feel free to do so - there is always the possibility that some case I didn’t think of has been omited.
Check your email for my test case 
Ok I know what the problem is… but am not sure if there is an exporter solution - i.e. I think you have to change your model. The problem is you have vertices with identical UV’s sharing an edge - this breaks the tangent/bi-normal calculation - both blenders and pandas algorithms fail in this scenario, and give tangents/bi-tangents of 0 length vectors, hence the problem being there whichever mode you select. The obvious solution is to change the model so there are no adjacent vertices that share a uv coordinate - the problem is the edges of your sidewalks where it drops down, but that is a horribly tedious task unless you have a script. I’ld consider separating them and giving them a different texture anyway, as the current one is not ideal for a lip anyway, though that is again something to consider scripting. Sorry I don’t have a better answer, but I can’t see a way of updating blender or pandas algorithms to cope with this, at least not in a reasonable way.
(This admittedly doesn’t explain why there is no diffuse texture when tangent/bi-tangent is deselected in the chicken exporter - I’m at a complete loss as to the cause of that - it looks correct when you read through the file.)
Uhm…yes…but with r51 (without “binormal/tangent” option) it works. So, why?
Well, my theory could be wrong, but I don’t think so - it works if I delete the sides, and looking through the output file its defiantly the case that the tangents and bi-normals are zeroed, which explains why the normal map doesn’t work. The thing is with the ‘tangent /binormal’ option deselected it calls panda to provide the tangents/bi-normals, which is completely independent of the version of the chicken exporter installed. (And when it is selected it uses blender, which is again independent of the exporter - it does not calculate the bad data itself, just moves it from a to b.)
I’m quite confused to be honest - are you sure the version of the exporter is all that has changed? i.e. panda and blender are both the same versions. Also, are you sure you didn’t make any changes to the file - recalculate the UV’s or something? None of the code for tangent/binormals has been touched since R51, so I’m finding it hard to see how it could be a problem with the exporter, unless I’m missing something - I still don’t understand the diffuse texture issue after all.
Ok, a more accurate test with r51:
-
Blender Binormal/tangent option doesn’t work with that mesh in r51 too…
-
…but Panda Binormal/tangent option (button is deselected) works!
I’m confused… 
What is wrong after this revision?
Well, taking the Sherlock Homes method, the only thing regarding texturing that has changed is the addition of support for texture options such as clamping, mip-mapping etc, as you well know! So it must be something to do with that, except I really don’t see how - this all has me confused basically. Have you tried comparing the files in a text editor? That might give some clues, and you could consider updating for the differences one at a time in the texture and material settings to see when it breaks.
What I will say is fixing the uv mapping defiantly fixes it though (I’ve tried.) - having vertices that share an edge with the same uv coordinates is simply wrong and will always cause graphical artefacts in that region of that edge. It just seems in this case that the graphical artefacts get everything else as well - I’m tempted to simply say this is input the tool can’t handle, as there is no reasonable way to handle duplicated uv coordinates. i.e. it may work with another version of the tool but it shouldn’t work with any version. Still, I would like to know why this is happening, but that is really a matter of curiosity.
After more tests, i can say the problem is in “UVTex” patch…If I revert it, the model appears as expected.
There is another problem related to that patch: I have a human model with 2 meshes, one for body and another one for hair. Each of these meshes has its material with different (from the other one) diffuse texture.
When I export it, the second texture disappears as in “sidewalks” case.
It works if I revert the patch.
I don’t know exactly what “UVTex” feature is, so can you look into this “bug”?
Which patch do you mean by the UVTex patch? i.e. a revision number would help as there is no patch with that in its description. I can have a look, but am at work right now, so that won’t be till this evening.
Ops, sorry… I mean the standard uv-name replacement feature requested by pro-rsoft which replaces all UVTex occurrences with an empty name (or something similar 
).
If i replace all blank names with “UVTex” (in texture declaration and vertex UV info in .egg files), models appear as expected. This change comes with r52.
Ah, makes sense now - I’m about to eat but will have a look after that. I can see several ways that can cause this failure, so this seems plausible. I really should of considered that your test case was highlighting 2 bugs rather than 1 earlier!
Ok, I’ve had a look at it… this is about to get long winded.
Above you state that for the sidewalk example with the tangent/binormal button selected (default, and better, state) it doesn’t work but with it deselected it does - I get precisely the reverse, and have tracked down why - I missed a case in the UVTex code. I’m guessing (hoping?) you just typed that the wrong way round, but if not am rather confused. (Button selected equals darker button btw.)
Now, for multiple objects things are rather screwy - they actually share materials and there textures between objects, which is fine if you are explicitly naming your uv coordinate sets in your materials, but if not can mess things up. This is due to the ‘default’ ability, to just use the first uv name on the list within blender not existing within panda. The problem is this is a fundamental design bug, and has been there for some time - fixing it is going to prove interesting. (I know the solution - append uv name to texture name when not blank, but it is not set up to do this so some extra fiddly changes will be required.)
So, that is two bugs… and I’m not convinced either is what your experiencing with the body/hair! I’ll fix both, but don’t have time right now. So, what do you think? If, as I suspect, I haven’t got the right bug then a test case that shows it would certainly help me get there. Alternatively a detailed description of how you have your materials, textures and object set up would help - I tried a whole host of combos, and whilst that second bug was always there I couldn’t get the scenario you described for the body/hair.
Also, what platform are you testing on and which Panda version? Theres always a risk we are running into a panda bug, and one that doesn’t appear for my scenario. (I’m at 1.5.4 btw, on 64 bit Ubuntu.)
Hello Everyone,
Sorry for posting such a rudimentary problem; I am having trouble installing r52 on my systems. I am running the latest blender build on both a mac and a PC and I cannot get chicken to work on either of them. I think I copied the chicken files into all of the right blender directories, but I still get a configuration error. The error on my mac reads, ““egg2bam” returned 32512. Perhaps your PATH environment variable is not properly set”, and the error on the PC reads, ““egg2bam.exe” not found. Perhaps your PATH environment variable is not properly set.”
What do these error messages mean and how do I fix the problem?
xelavelobos, they mean that Chicken can not find panda - there are several utility programs that Chicken will make use of if it can. The solution is to make sure panda’s bin directory is in your path. I don’t know about mac or vista but under windows XP right click ‘My Computer’, go to the advanced tab and at the bottom is a button that says ‘Environment Variables’. Click on it and add the panda executable path to the end - it needs to be seperated by semi-colons, so something like “;C:\Panda3D-1.5.4\bin” needs to be added. For the others you will need to google as thats the limit of my OS knowledge I’m afraid, unless someone else here knows the answer.
However, saying all that my understanding is that Chicken should be able to run independent of them, just without the extra functionality, so it should still work. Of course, because all of us testers have the previous set up it wouldn’t surprise me in the slightest if that was not the case.
Thanks for your work 
My test environment:
- Windows XP SP2 (32bit)
- Panda 1.5.4
- Blender 2.48a
Check your email for my human test model