Blender .Scene Exporter

[Robomaniac]

It would be nice to see a free alternative to the 3ds exporter to .scene. Blender would be nice, a standalone editor (like Chronos) would be perfect too

[nfz]

Christmas is just around the corner. I've already written my letter to Santa for what I want which has a world editor at the top of the list.

[Vectrex]

I'd really like to see a blender scene exporter too. In fact if anyones doing a fuller editor they should look at working it into blender. I just started looking at it and at first glance it looks real nice (and small too)
Seeing as most of us are cashless indies then it'd be especially nice to not need 3dsmax or even xsi. Blender has funky python scripts for alot of things too.
www.blender.org

[reimpell]

The Blender exporter is slowly moving towards scene exporting. If somebody likes to speed up development, the following has to be done:

1. Review of ogreaddons/dotsceneoctree. At a first glance there seems to be a lot of code that is commented out. Does it still provide basic functionality with the latest Ogre version? Does the ExampleSceneConverter correctly split a dotscene into an octree?
2. Add files for GNU Autotools build system to ogreaddons/dotsceneoctree. The DotSceneManager should work out of the box with a (patched) CVS Ogre on linux.
3. Enhance dotsceneoctree/Samples/DotScene to load a scene given on the command line. If cameras are defined in the dotscene file, the sample application should allow to switch between these camera views and use a default camera otherwise.
4. Convince Sinbad to merge the ogreaddons/dotsceneoctree into ogrenew so that patching of the OgreSceneManagerEnumerator is no longer necessary.

[mac]

4. Convince Sinbad to merge the ogreaddons/dotsceneoctree into ogrenew so that patching of the OgreSceneManagerEnumerator is no longer necessary.

It is not necessary to patch Ogre anymore.

So 3 from 4 remain...
HTH, mac

[psyclonist]

1 & 2 can be ignored if you don't use the dotSceneOctree scene manager but one of the other ones instead.

-psy

[reimpell]

1. Review of ogreaddons/dotsceneoctree. At a first glance there seems to be a lot of code that is commented out. Does it still provide basic functionality with the latest Ogre version? Does the ExampleSceneConverter correctly split a dotscene into an octree?
2. Add files for GNU Autotools build system to ogreaddons/dotsceneoctree. The DotSceneManager should work out of the box with a (patched) CVS Ogre on linux.

Done, see [ 1081311 ] DotSceneOctree autotools integration.

[ibrown]

.scene export from blender would be really useful. Even a partially working export is better than having to put the .scene together by hand!

Is there any work currently being done on this? Looking at the export script ... it seems that most of the hard work has been done and what remains is to iterate over the objects in the blender scene to write the .scene. I'd give it a go myself, but I'm still trying to get to grips with blender itself

Ian

[reimpell]

Is there any work currently being done on this? Looking at the export script ... it seems that most of the hard work has been done and what remains is to iterate over the objects in the blender scene to write the .scene.

Yes, I'm still working on it. I still need

1. A sample application that loads the current dotscene format to roam around and where I can switch between the camera views defined in the scene.
2. Some test scenes as .blend files including multiple static and animated meshs, lights and cameras.

[ibrown]

9th life loads .scene files and allows you to walk around them. I suspect that you want something more like a utility though.

I'm looking at doing a RPG like 9th life but using open tools such as blender for defining the .scene rather than having to use max.

The 9th life resources have a number of .scene files in there that you can use as a reference ... it's not the ideal situation for sure but it's a start. I think that as soon as we have a very basic scene export capability then we'll be able to develop the tools to test the output. At the moment though, we're in a bit of a chicken and an egg situation. Still, there is a .scene DTD so you could begin by exporting a .scene that validates correctly with the DTD and if the blender scene is simple enough (say 2 cubes) then it should be possible to check the mesh export positions in it by hand.

In the mean time, I'll try and re-create on of the simple 9th life scences from scratch in blender...

Ian

[ibrown]

Hi reimpell,
I've put together a really simple .blend file that contains a wall and a floor. I have also hand-coded a .scene file that can be read by the scene viewer. I'll continue to work on the hand coded .scene file so that it properly represents the view in blender ... but what I have so far should be enough to give you a start. Bear in mind that I am a c++ coder and not an artist, so the blender file is pretty simple.

Grab the file from here:
http://www.ijbrown.net/ogrestuff/blender_work.zip

In the zip file there is an export directory. If you load area1.scene with the scene viewer you can see the scene. I think the clip plane of the camera is wrong at the moment so you will need to scroll the view out (use the mouse wheel). Also pressing 'B' to turn the bounding boxes on helps to orient yourself in the scene.

The scene viewer I am talking about is the DSISceneViewer that is in ogreaddons/dotsceneformat. You need to use CVS head and checkout ogreaddons under ogrenew (but I guess you know all that already). You probably also want to apply the small patch to the viewer so that you can browse for .scene files. Look for this in the development forum - the title is .scene viewer fix .... it's only a few lines.

I'll continue hacking the area1.scene file in my spare time to try and get the camera correct. If there is anything more useful you would like me to take a look at, let me know.

Ian

[reimpell]

Many thanks for the test scene, ibrown! As the available dotScene loaders/viewers seem to get adapted to the latest dtd, less work has to be done for a utility that allows for a visual check of .scene files, especially the camera perspectives. A preliminary version of the scene exporter is almost done, I'll give a download link when it's in a working state.

[ibrown]

A preliminary version of the scene exporter is almost done, I'll give a download link when it's in a working state.

That's great news!

Ian

[bana]

I am also very happy to hear about this, I for one am very appreciative of all the work that Reimpell has put into the blender exporter and hope that you continue to support it as it is a great addition to the OS community

[IoN_PuLse]

I also would like to extend my thanks, I'm going to be heavily using the Blender export script and hopefully soon the .scene exporter, I also have python experience so I can test and maybe even help add features or fix bugs

[walaber]

I would also like to say a quick thanks for the wonderful blender exporter, it works really well, and has become my main way of getting content into Ogre...

I'll have to investigate the dotscene format, it looks very interesting as well!

[reimpell]

A preliminary version of the scene exporter is almost done, I'll give a download link when it's in a working state.

Just to ensure you that we are not talking about vaporware, this is how the preliminary version is going to be. At the moment, you will have to additionally export all meshs seperately with the ordinary export script (Revision >= 1.26). I'm still struggling to get the DSISceneViewer to work to test even the simplest test scenes. This means that the above script is completely untested. Once I know the conversion results are close to their Blender counterparts, I will add all these convenience features to the script and write some documentation.

[reimpell]

I just started the first few tests: If you export the meshes be sure to disable the "World Coordinates" option, set Scale = 1.0 and RotX=RotY=RotZ=0.0. The material file has to be named after the scene (this is the default, else do shift+LMB, shift+backspace, enter on the corresponding string button).

[ibrown]

wow, you've been working hard - that's not a trivial script!
Thanks for the efforts here - blender .scene export is a key part in being able to use Ogre without the need for commercial software.

I'll do what I can to help test it...

Ian

[stenyak]

Looks like a great idea to me

You'll hear from us (Motorsport project, see sig) sometime soon; we're willing to help blender become our contents creation tool, and this exporter looks like the ideal way to achieve it.

Thanks for your work!

[ibrown]

Hi Stenyak,
I'm thinking that this will be a great tool for track creation. You can do a lot to blender with python scripts, so it would be possible to add menus to do special things like adding different types of surface etc. The work that reimpell has done so far is very impressive, so I think the final version of this script will really fit the bill for motorsport.
Anyhow, that's off topic.

Ian

[stenyak]

I'm sure others will also use this scene importer for the creation of contents for their games. I'd like to show one of the problems i see in the scene importer right now. I know it's new and will go through many changes, but well here goes:
-All games will (most probably) have more data than that stored in a .scene file.
-Also, many games (replace 'games' with project or whatever) won't make use of all the data in .scene file. For example, a game may not take into account any of the cameras the may be present in the blender files, because the game is a FPS with only a first person camera.
-And finally, many games will need to 'override' the values provided in .scene files. For example, in Motorsport all the ambient color values are computed on the fly based on the time of day.

The 2nd and 3rd problems could be solved this way: there could be a way to 'mask' some properties, so that they don't get exported to the .scene file. This way, people won't struggle modifying the .scene file wondering why their changes make no effect in the game.


For the 1st problem.. it's a bit offtopic in this thread, but maybe it can give ideas on possible features for the scene exporter. Right now the best solution i've thought of (not integrated with the scene exporter):
-Create some additional gui controls for blender via python scripts. With this gui you can modify/add your custom game data. For example, the "initial damage points" of an object, or "mass" of a car, etc...
-The python script that controls this gui would then be able to export this additional data to your custom game file format.
-After this, you use the .scene exporter and create a .scene with the appropriate name in the appropriate path so that your game finds it together with the game files (which contain the "additional data".

Any thoughts?

[reimpell]

-All games will (most probably) have more data than that stored in a .scene file.

Note that the above script is just a preliminary version. Exporting all object properties (as defined with Blender's Logic buttons) as userDataReference is already on my todo list.

[stenyak]

-All games will (most probably) have more data than that stored in a .scene file.

Note that the above script is just a preliminary version. Exporting all object properties (as defined with Blender's Logic buttons) as userDataReference is already on my todo list.

Ah ok. I'm not an expert in blender, i didn't know about that feature in blender, it looks very useful.
So from what i see, the "gui" part i mentioned is already integrated in to blender.

Now there's the problem of exporting all this custom data to the "custom file formats". For example, in Motorsport we use xml; some people may use .ini files, etc...
I think that the best solution for this would be to allow some kind of "plugins" to be used in your exporter.
For example, i create a motorsportCustomDataExporterPlugin.py. This code is called by your exporter, so that my exporter gets a list of property names, types and values. My exporter would take care of exporting all that data to the xml format we use.
Following the example, other projct may use .ini files. The people from this project create a otherprojectCustomDataExporterPlugin.py. This plugin is called by your exporter; it's given the list of properties, and it writes to their .ini files format.
Etc...

What do you think about it? Maybe just outputting it to xml, then using xslt would be better?

[reimpell]

Now there's the problem of exporting all this custom data to the "custom file formats".

DotScene is already meant to be postprocessed, e.g. see ogrefsrad, dotsceneoctree. You can either do that or modify the exporter to suit your needs. After all, this is one of the key advantages of open source!;) With its object oriented design, there should be no need for hooks in the exporter. Just derive from the corresponding ObjectExporter and modify the ObjectExporterFactory to call your classes. If you define your classes in a separate module all you have to do when a new script version comes out is to import your module and replace the ObjectExporterFactory. A simple example would be

Code: Select all

class MyMeshExporter(MeshExporter):
  def writeSpecificNodeElements(self, sceneExporter, fileObject, indent=0):
    # call base class code
    MeshExporter.writeSpecificNodeElements(self, sceneExporter, fileObject, indent)
    # custom object processing
    # self.object is the corresponding Blender object
    print "Processing object: ", self.object.getName()
    return

together with

Code: Select all

class ObjectExporterFactory:
	def create(object):
		exporter = None
		if (object.getType() == "Mesh"):
			exporter = MyMeshExporter(object)
		elif (object.getType() == "Lamp"):
			exporter = LampExporter(object)
		elif (object.getType() == "Camera"):
			#disable camera
			#exporter = CameraExporter(object)
		return exporter
	create = staticmethod(create)