irrb 0.4 (Blender Exporter)

[Oktyabr]

As for more on topic have you experimented with any of the Blender 2.50 releases yet? Do you see any complications with using irrb and 2.50 either at present or that might arise in the future? I've been dabbling with the 2.50 daily builds quite a bit lately and while I currently fight off the temptation to use it for "production work" I do plan to migrate to it ASAP!

[pc0de]

I'll let you pick the destination

Let's wait for the Irrlicht devs to pre-announce the next competition.

...anything I could do to help keep this from turning into abandon-ware...

I guess you could offer up a prayer that I don't get hit by a truck. To be truthful, the only reason I would abandon irrb is readblend, but I'm still working out the pros/cons in my head of whether or not it makes sense to do so. Eventually I'll solicit the communities thoughts in a separate thread.

As for more on topic have you experimented with any of the Blender 2.50 releases yet? Do you see any complications with using irrb and 2.50 either at present or that might arise in the future?

Yes. No. The current version of irrb won't work with 2.5+, but I don't foresee any problems with the update. Most of the changes are related to the methods used to access Blender's internal data.

[erwincoumans]

To be truthful, the only reason I would abandon irrb is readblend, but I'm still working out the pros/cons in my head of whether or not it makes sense to do so. Eventually I'll solicit the communities thoughts in a separate thread.

No need to drop your irrb project, both irrb and readblend have their benefits and drawbacks I suppose. It would be good if both projects can benefit from eachother.

We re-implemented readblend .blend file reading in C++ bParse. Right now we convert data from a .blend into either Irrlicht and Ogre, to keep things generic. Skeletal animation and skinning is only created for Ogre at the moment, but hopefully we get an implementation for skeletal animations for Irrlicht too.

I have to admit that I haven't tried irrb yet, but I should do that soon.
Happy 2010,
Erwin

[torleif]

I've made a patch to the irrb plugin allowing users to add custom scene nodes. You select what object you want to change, and type in the new custom scene node:



Download the irrb .4 fork here

(It's kinda a hack, there's not really enough space to add many custom nodes. I'll look into it if it pisses enough people off. )

I also might make a patch that copies the images to the tex/ folder. It's annoying having to rename all the folder paths afterwards.

[pc0de]

It would be good if both projects can benefit from eachother.

Agreed.

@torleif:
Thanks for the idea. I'll add the ability to export a custom scene node using the "inodetype" Blender ID property (currently used for billboards & skyboxes).

As far as the ability to copy images goes - Note that irrb automatically saves packed images to the texture/image output folder ("tex/" by default, but it can be overridden in UserConfig.py). Modified the original packed image? no problem - use "reload" in the UV editor to pull the updated image into Blender.

Assuming you're not using packed images, can you give an example of why you're having to rename folder paths after the export? Thanks.

[torleif]

Thanks for the idea. I'll add the ability to export a custom scene node using the "inodetype" Blender ID property (currently used for billboards & skyboxes).

As far as the ability to copy images goes - Note that irrb automatically saves packed images to the texture/image output folder ("tex/" by default, but it can be overridden in UserConfig.py). Modified the original packed image? no problem - use "reload" in the UV editor to pull the updated image into Blender.

Assuming you're not using packed images, can you give an example of why you're having to rename folder paths after the export? Thanks.

Using the inodetype for the custom scene node is a much better idea, I didn't think of using that.

I'm having to rename the images atm as I'm using external images. The paths are relative to the blender file, not the irrlicht scene file. I'll pack the images in to blender for the time being, but it would be cool if irrb could automagically copy them to the texture folder.

[pc0de]

I'll add an option to copy non-packed images that aren't located in the irrb output image directory.

[erwincoumans]

It would be good if both projects can benefit from eachother.

Agreed.

I just browsed the irrb user manual and it looks nice. Our gamekit project has similar features to Tubras, and perhaps we can add a similar walktest like 'iwalktest' to gamekit. Also you might want to add rigid body constraint support (for ragdolls, hinged doors etc). You can check out gamekit for this.

I wonder about the following quote:

The respective files sizes and load times are:

• yoda.irrmesh - 4,713,164 bytes loaded in 24.6 seconds.
• yoda.b3d - 1,521,446 bytes loaded in 124 milli-seconds.
• yoda.irrbmesh - 2,548,107 bytes loaded in 17 milli-seconds.

What are the approximate export time of irrb for this toda .blend. I'm interested in the export timings of irrb python script that exports to toda.b3d and yoda.irrbmesh.

Do you have the yoda.blend available somewhere?

Thanks,
Erwin

[pc0de]

Also you might want to add rigid body constraint support (for ragdolls, hinged doors etc).

Yes, yes I would like to add support for constraints.

...I wonder about the following quote...

No need to wonder as you can test it yourself. Here's a link to the compressed .blend: yoda.blend. The screen shot of the load times in the user guide was created with version 0.3 (neglected to update the guide). The 0.4 times haven't changed all that much (AMD Athlon 64 4000+ 2.52GHz 1GB):

Code: Select all

c:\gdev\tubras\bin>imeshcvt -i \scenes\mdl\yoda.irrmesh
imeshcvt 0.4 Copyright(C) 2008-2009 Tubras Software, Ltd

 Input Mesh: \scenes\mdl\yoda.irrmesh
Output Mesh:

--------------- Mesh Info ----------------
      Load Time: 20169ms
      Mesh Type: UNKNOWN
   AFrame Count: 1
  ABuffer Count: 1
 Material Count: 1
   Buffer Count: 1
   Vertex Count: 31915
 Triangle Count: 62944

c:\gdev\tubras\bin>imeshcvt -i \scenes\mdl\yoda.b3d
imeshcvt 0.4 Copyright(C) 2008-2009 Tubras Software, Ltd

 Input Mesh: \scenes\mdl\yoda.b3d
Output Mesh:

--------------- Mesh Info ----------------
      Load Time: 117ms
      Mesh Type: SKINNED
   AFrame Count: 0
  ABuffer Count: 1
 Material Count: 0
   Buffer Count: 0
   Vertex Count: 0
 Triangle Count: 0

c:\gdev\tubras\bin>imeshcvt -i \scenes\mdl\yoda.irrbmesh
imeshcvt 0.4 Copyright(C) 2008-2009 Tubras Software, Ltd

 Input Mesh: \scenes\mdl\yoda.irrbmesh
Output Mesh:

--------------- Mesh Info ----------------
      Load Time: 18ms
      Mesh Type: UNKNOWN
   AFrame Count: 1
  ABuffer Count: 1
 Material Count: 1
   Buffer Count: 1
   Vertex Count: 31915
 Triangle Count: 62944

You can view the imeshcvt timing code at: imeshcvt.cpp.

What are the approximate export time of irrb for this toda .blend. I'm interested in the export timings of irrb python script that exports to toda.b3d and yoda.irrbmesh.

Umm... well... 44 seconds to generate yoda.irrbmesh. But, that's a two step process: (1) irrb -> yoda.irrmesh, (2) irrb then invokes imeshcvt yoda.irrmesh -> yoda.irrbmesh. 20 seconds of which are used for loading the .irrmesh file. I guess irrb could eventually write directly to the .irrbmesh format.

The .b3d exporter takes approximately 3-4 seconds to generate yoda.b3d.

[Jacky_J]

inside iConfig.py you have texture and model path. You should have another variable called "scene path", because my scene path != base path.

Thanks

[pc0de]

Done in pre 0.5. Added 'sceneOutDir' to iConfig.py (may also be overridden in UserConfig.py). Defaults to '.' which causes the scene file to be saved to "Output Directory".

Also Updated:

• irrb.log is now saved to the "Output Directory" instead of the scene directory.
  relative/absolute check is now 'path'[0] == '/' or 'path'.find(':') >= 0

So if you want to use absolute paths for your scene, mesh, and/or texture directories, start them with a '/' or include the drive letter and a ':'.

So there it is, 0.3 functionality restored with the "good" stuff under the covers.

[Jacky_J]

Thanks pc0de. When do you think 0.5 will be out?

irrb needs its own forum.

[pc0de]

When do you think 0.5 will be out?

As you may have already seen in this thread, my irrb estimates have been somewhat lacking. Okay, completely inaccurate. So... here's what's currently in my head:

0.5 (Blender 2.49b) - bug fixes, particles, and possibly constraints. 1-2 months.

0.6 (Blender 2.6) - irrb 0.5 functionality working in Blender 2.6. 2-3 months.

To get the above updates it will likely be quicker to pull from svn:

Code: Select all

svn co https://tubras.googlecode.com/svn/trunk/tools/irrb

Copy irrb.py and the irrbmodules sub-directory to your Blender scripts directory.

[torleif]

Bug found: exporting a skybox crashes if the skybox contains no material. The material is not used in a skybox.

Line number:

Code: Select all

  File "/Users/etc/Desktop/blender-2.49b-OSX-10.5-py2.5-intel/blender.app/Contents/MacOS/.blender/scripts/irrbmodules/iScene.py", line 570, in writeSkyBoxNodeData
IndexError: list index out of range

[pc0de]

Thanks for the report torleif - fixed in 0.5.