The Ogreloader product is no longer part of Radakan, as they have switched from Java to Python. The Ogreloader users are quite keen to have it moved to jME base. Quite imperfect, but well exercised and completely compatible with jME 2.0 HEAD. Total of only 29 source files plus a dozen sample data files. It works fine where it is, but I think merging would be a net gain for the jME product. I can do the merge if it's desired.
What do you think?
If yes why not? 
+1 for me 
Yes it would be fine as I have some .mesh files, I don't succeed in converting them into XML meshes (I failed in using OgreXMLConverter) then I have no way to load them into Blender (I have a script to load only XML meshes, not binary ones) to convert them into another format.
Sorry to say this gouessej, but ogreloader also only imports the xml variety of ogre files. Though it supports both mesh and scene varieties. At least, that's my understanding, I'm currently using it to import xml meshes and hope to be using the scene importer soon as well. It does have it's flaws, but it's one of the best art pipeline solutions I think jME2 has, so I fully support merging it into jME's codebase. Also means one less project in my eclipse. It was starting to get crowded, with jME, ogreloader, Hard Boild, and then all my classes and projects for school, thank goodness the semester is over, I can start clearing stuff out. Anyway, +1 vote here, if it counts for anything.
+1…it's turning out to be the model format that i'm having the most success with…
Sorry to say, but I withdraw delay my offer to merge, based on issue at http://www.jmonkeyengine.com/jmeforum/index.php?topic=11040.0. It’s looking like, regardless of cause, it was not over-zealousness. Just holding off to ensure I can depend on my future work being saved.
Do you want me to comply with the Radakan license, concatenating the jME boilerplate and the Radakan boilerplate, or should somebody seek out the copyright owner, Gibbon Entertainment, for permission to remove their license? I suspect they would not care… if only they can be located.
blaine said:
Do you want me to comply with the Radakan license, concatenating the jME boilerplate and the Radakan boilerplate, or should somebody seek out the copyright owner, Gibbon Entertainment, for permission to remove their license? I suspect they would not care... if only they can be located.
'Gibbon Entertainment' is the team that worked on the Java-based Radakan RPG. Since the OgreLoader was created by me (with minor changes by other members) it should be okay to remove the license and replace with jME's.
Momoko_Fan said:
blaine said:
Do you want me to comply with the Radakan license, concatenating the jME boilerplate and the Radakan boilerplate, or should somebody seek out the copyright owner, Gibbon Entertainment, for permission to remove their license? I suspect they would not care... if only they can be located.
'Gibbon Entertainment' is the team that worked on the Java-based Radakan RPG. Since the OgreLoader was created by me (with minor changes by other members) it should be okay to remove the license and replace with jME's.
I've been through this before when I merged in some retired third party stuff to the JWebmail project, and the following request is based on legal requirements. Could you confirm for the record that you are releasing the license for the Ogreloader portion of Radakan, on behalf of Gibbon Entertainment, for JMonkeyEngine?
I have added merged code bases with history (even from CVS) to existing repositories at Sourceforge, but it looks like Googlecode doesn't support this. It could be done with "svnadmin dump", "svndumpfilter", and "svnadmin load", but these commands are only available on the server-side, and I don't believe Googlecode gives that privilege out to anybody. It would be helpful if a Googlecode project admin could confirm this.
According to these two docs at Google, it looks like you can only import history if you are starting your repository over from scratch. Otherwise, they tell you to use "svn import", which doesn't do anything close to what we want.
- http://code.google.com/support/bin/answer.py?answer=56673&topic=10386
- http://code.google.com/support/bin/answer.py?answer=56669&topic=10386
Unless somebody has a good idea, I'll have to import the code without any history. Anybody who wants historical details before the merge will have to go back to the Radakan repository :(.
blaine said:
According to these two docs at Google, it looks like you can only import history if you are starting your repository over from scratch. Otherwise, they tell you to use "svn import", which doesn't do anything close to what we want.
That is correct, we would have to reset the repository which is not a realistic option in my opinion.
I don't see why not to include OgreLoader, its got my vote. It would go into jmex, right? Also, I prefer that it be complete with a working example in the tests and it would be really nice to have some decent documentation put up as to what it can and can't handle. I just don't want to see something like this added and then forgotten in an incomplete state that noone knows or can use.
nymon said:
blaine said:
According to these two docs at Google, it looks like you can only import history if you are starting your repository over from scratch. Otherwise, they tell you to use "svn import", which doesn't do anything close to what we want.
That is correct, we would have to reset the repository which is not a realistic option in my opinion.
With Google's monetary and skill resources, I think they should at least match Sourceforge's SCM capabilities. They do not.
I don't see why not to include OgreLoader, its got my vote. It would go into jmex, right?
I'm going to import it with the same exact package structure that it has now. This will facilitate testing for the many existing users, and will make a clean "merge" task.
In order to keep things moving quickly and properly track the tasks, I want small, atomic steps. I don't want to bog down the merge step and testing thereof by renaming everything. If something doesn't work, I want to know whether the problem arose during the merge, the rename, or some other step.
Also, I prefer that it be complete with a working example in the tests and it would be really nice to have some decent documentation put up as to what it can and can't handle. I just don't want to see something like this added and then forgotten in an incomplete state that noone knows or can use.
I appreciate that goal, but I have reasons why this will not happen without having to handicap the dev process with a monolithic merge + demo-test-effort:
- Ogreloader already has an active jME user base, and these users have been quite vocal about the desire to merge to jME. They are not suddenly going to stop using it.
- Recent work, such as supporting general object nesting and general transparency, fixing several bugs so that non-material meshes now work, plus active work like Wizem's Savable implementation (to allow for conversion to other formats like jME native binary), are broadening the applicability of Ogreloader.
- ToM ("ttrocha") already has a popular tutorial, and we have agreed to port this to the jME Wiki, and I'll improve it along-the-way.
- Ogreloader already comes with excellent and popular sample data. I have a Webstart app that we can href to, which automatically allows the (java 6) user to display these models and manipulate the animations.
- You can check the recent Radakan deltas and see that in the past week I have steadily improved the Javadoc API spec to the point where it actually expains how-to-use critical pieces, and non-intuitive aspects, as opposed to just listing the methods (which latter is the case for much of the jME code base).
To recap, yes, for consistency we should add test programs under src/jmetest; but IMO, no, this requirement is non-essential to the merge process, since there is already adequate user documentation and test programs and data. If you want the Ogreloader code base in jME, I can do it quickly, as soon as Momoko_Fan acks the license change; and we can then discuss following tasks like permanent package locations and jME-consistent demos and tests.
blaine said:
I've been through this before when I merged in some retired third party stuff to the JWebmail project, and the following request is based on legal requirements. Could you confirm for the record that you are releasing the license for the Ogreloader portion of Radakan, on behalf of Gibbon Entertainment, for JMonkeyEngine?
I approve the license removal from the OgreLoader part of the Radakan project so that it can be merged with jMonkeyEngine on behalf of Gibbon Entertainment.
Could existing Ogreloader users please update your jME work areas from HEAD and rebuild the jME dist, change your app build and runtime classpaths to exclude the Radakan stuff and use the new target/jme-ogreloader.jar, and test your apps? At this stage, no coding changes should be required.
FYI, this is not how things will stay. To be consistent with jME, the classes will be moved around, and jme-ogreloader.jar could be eliminated (the pieces being allocated to the appropriate existing jME distributable jars), once we know everything works.
Momoko_Fan said:
blaine said:
I've been through this before when I merged in some retired third party stuff to the JWebmail project, and the following request is based on legal requirements. Could you confirm for the record that you are releasing the license for the Ogreloader portion of Radakan, on behalf of Gibbon Entertainment, for JMonkeyEngine?
I approve the license removal from the OgreLoader part of the Radakan project so that it can be merged with jMonkeyEngine on behalf of Gibbon Entertainment.
Great. Thanks very much. I'll start on it later on this morning.
UNRELATED:
[glow=yellow,2,300]If anybody is working on a patch for Ogreloader, please PM me ASAP. The different steps of the merge may result in merge conflicts. This can be minimized with some preparation.[/glow]
All of the imported resources have been moved to appropriate locations. This phase definitely does require modification of apps that use Orgreloader.
Due to considerable updates to build.xml, I'd appreciate it if anybody out there could clean and rebuild, and restest your apps, even apps which don't use any model loading at all. I.e. regression test. Just contact me and I'll fix any issues which may arise.
For the Ogreloader crowd: You need to update your classpaths and distro builds to drop any jars which used to contain the com.radakan classes, and add jme-model.jar (if you don't already include it) and jme-ogrexml.jar. Then edit your code to satisfy the compiler. UPDATE: The working examples in src/jmetest/ogrexml may be helpful to you. As I write this, there are only examples for loading *.mesh.xml files, no example for loading a dotScene file. I'll see if I can work up a dotScene example quickly now.
If anybody doesn't like the packages where I have placed things, now is the time to debate it, to minimize effects to the innocent.
The test/demo programs do build cleanly, but they will not run successfully yet. I needed to get this post out ASAP so people know why their ogreloader apps have stopped building successfully (until you update as directed above). I'm going to get the test programs working now. UPDATE: Done
All existing Ogreloader resources have been merged in, completing with rev. 4317. I'm going to work on a dotScene example now. I know of no such example in the Radakan repository.
UPDATE: I've added src/jmetest/ogrexml/TestDotScene.xml. This both shows off the animation capabilities of the loader, and also provides a meaningful example of dotScene file loading. Will probably make this example more interactive next week.
Hi Blaine,
blaine said:
Due to considerable updates to build.xml, I'd appreciate it if anybody out there could clean and rebuild, and restest your apps, even apps which don't use any model loading at all. I.e. regression test. Just contact me and I'll fix any issues which may arise.
For the Ogreloader crowd: You need to update your classpaths and distro builds to drop any jars which used to contain the com.radakan classes, and add jme-model.jar (if you don't already include it) and jme-ogrexml.jar.
I updated the jme2 sources (found the new com.jmex.model.ogrexml package) and I rebuilt the project, generating new jars, including jme-ogrexml.jar
Changed the imports of all my Ogre classes and executed them.
They work fine - and the alpha value bug is fixed, too.
Great work !
I need a little help finding the new Ogre Jars
(http://jmonkeyengine.googlecode.com/svn)
I got the 2.0 branch and dont see any of the ogre jars
What code am i supposed to pull down
and what is the package name that includes the ogre scr
Thanks,
Greg