While I understand as well as anybody the importance of minimizing platform-specific artifacts in a Java project, it’s typical and useful for even pure Java projects to CM platform-specific scripts and wrappers. I submit as an example the HSQLDB database (soon to be relabeled to HyperSQL) project, a pure Java database for which I am an admin. There is no project which is more pure Java, yet we supply optional convenience wrapper scripts and platform-specific sample app scripts, etc.
I propose moving my long-standing shell script referred to at step 6 of http://www.jmonkeyengine.com/wiki/doku.php?id=chapter_1_-_getting_started into an appropriate subdirectory of the code base. (As I am the copyright holder, I can switch it to the JME license).
I propose moving the Blender export scripts from the abandoned jmexml project to an appropriate subdirectory of our code base. The admin of the jmexml project is unreachable (believe me, I have been trying), and neither I nor anybody else can work on that project.
Could JME admins please approve or reject? If reject, I will have to branch jmexml to my own new Google code project, and I really don’t want to assume that maintenance responsibility just to CM a few files. The urgency for this is that I am investing much effort to improving this exporter and for good reasons which I won’t enumerate here, I very much need to CM this work.
I am for that 
for wiki attachments I think hosting them on the jME server itself would be appropriate, but we don't have access (only the original authors still do)…
i think it dosent hurt to check-in start scripts for linux/windows/mac, i think will help newcomers to get started.
As for the blender exporter script, i think it makes sense to have it provided with the jme source since it needs to be updated when jme changes.
After investing much time into improving the existing jmexml project's Blender exporter, it's become clear that it is an inadequate base for a professional quality product (as the original author told me, that was never the intention). I am making an object oriented, fully unit tested, modular, JME-2-only, Blender exporter. Instead of hacking to get it ready for public use ASAP, I'm using the agile method to make sure every feature added is bulletproof. The output files will definitely remain JME XML compatible, and will also be jmexml downward-compatible. It would be impossible to complete this exporter, including unit testing infrastructure, distribution packager, etc., if I had to wait for JME forum approval for each file addition, so I want to make a work branch in the JME repository. I will create a new, empty work branch for this tomorrow if nobody objects. When the feature set is ready for public use, it can be merged into a new directory in trunk if approved, otherwise I can export the branch to a new, independent project. I…e., if the work isn't approved, JME trunk will not be effected at all, yet the output of my work will not be lost.
Regardless of the state of this new exporter, the jmexml project exporter will continue to be useful for pre-v2 JME support.
go blaine go
let us know when you want some testing…
I have no reservations, go for it.
basixs said:
go blaine go :)
let us know when you want some testing...
Ready for testing. Pre-built distro is at http://pub.admc.com/misc/jme/. Get the latest version that is there when you look. Just extract the zip into your Blender "scripts" directory.
I'm doing my dev work on Linux. It would be good if somebody could try building a distro and running the unit tests on Windows. I've documented the testing procedure at "doc/testing.txt". http://jmonkeyengine.googlecode.com/svn/branches/blenderjme. Unfortunately, though I have the infrastructure and scripts all set up to test exporting Blender scenes, the basic Blender python command to load scenes is barfing with a fragmentation error for me. So, only the standalone XML module can be unit tested until I troubleshoot my Blender problem.
An easy task for somebody would be to add negative XML tests, following the existing tests. Python's "unittest" module is just like JUnit.
Of course, if anybody wants to help develop... It's a good opportunity to learn how to do Python coding right. Program behavior, diagnostics, output XML format, all are in a different league from the old JME XML exporter. I already have several small features missing in the old one: QuadMeshes preserved where possible, automatically conform to jME-native axes, ability to export selected or all supported objects; and the XML output is much more consistent (besides rigorously validated).
THIS IS PRE-ALPHA. Don't waste time telling me that the Gui needs adjustments or that features are missing. What is there should work very smoothly, but all it can export is static meshes (TriMesh or QuadMesh) with normals. No materials, no vertex coloring. I will get vertex coloring and basic materials working quickly... as soon as I conquer the problem below.
I wasted 8 hours today troubleshooting an issue I ran into last week. I finally realized, by running regression tests, that the problem is a longstanding bug, probably in the jME code base, but possibly in Blender's quaternion implementation. Quaternion transformations which work perfectly well in Blender do not orient the model correctly upon import to jME (could be that they are self-consistent but incorrect in Blender-- TBD). Only occurs for nontrivial quaternions, but I can easily reproduce the problem. So, just as complex transl. + rot + scales do not work with the jmexml project's exporter, they won't work in mine until I get this fixed. I'll be working on this tomorrow.
Worked around Euler incompatibilities between Blender and JME. Nontrivial transformations with rotations will get hosed by the jmexml project exporter. Mine handles all varieties transformations now. Vertex coloring is working.
Would appreciate any testing. Somebody out there must use Blender. Download latest zip from http://pub.admc.com/misc/jme/ .
Next up is preserving scene node nesting. This will be somewhat tricky because (a) Blender hides some extra nodes that it adds in order to keep local transformations as simple as possible in the most common cases; and (b) the Euler incompatibility issue (which trickles down to quaternions too).
Sorry I havn't had a chance yet blaine (works been kicking my @$$), will try to get to it later today or tomorrow (thank goodness for weekends eh?)…
i found a funny behavior.
export -> then abort, and the currently selected mesh gets rotated 90
Core-Dump said:
i found a funny behavior.
export -> then abort, and the currently selected mesh gets rotated 90