Jump to content

Export error with lights blender and babylon js


Recommended Posts



I'm using Blender 2.7.2 with babylon js, I'm trying to export a musicbox (coming from a .obj) in .babylon but when I drop it in the babylon sandbox the lights don't work, they're not the same as in blender.


If anybody know a solution that be great, you can a capture of what I get in the sand box below. 


Thank you post-11941-0-61730100-1417616130_thumb.p

Link to comment
Share on other sites

DK, that is a bug that I discovered.  Hemi lights are pointing in the wrong direction due to an incorrect sign of last dimension, z I thing. I have had no luck figuring it out.  The original exporter  had:

        else:            matrix_world = object.matrix_world.copy()            matrix_world.translation = mathutils.Vector((0, 0, 0))            direction = mathutils.Vector((0, 0, -1)) * matrix_world            Export_babylon.write_vector(file_handler, "direction", -direction)

The multi-pass is:

        else:            matrix_world = light.matrix_world.copy()            matrix_world.translation = mathutils.Vector((0, 0, 0))            self.direction = -(mathutils.Vector((0, 0, -1)) * matrix_world)

Do you know why the sign ends up wrong?  I have tried a number of ways, but no joy.


Johgold,  you can manually change the sign in your .babylon file as a temp fix.

Link to comment
Share on other sites

That did it.  That stray '-' in Export_babylon.write_vector(file_handler, "direction", -direction)  must not have been doing anything, and when I re-factored it, implemented in a way where it did.


I just tested in TOB.  There are now un-needed ().  I was in the process of diffing the 2 today, in Netbeans.  I have changes for you.  Either code you are not using, but did not remove, comments, or improved log entries.  Will put in pull request & take care of parens + update version #.



Link to comment
Share on other sites

Have made changes locally, and just going to turn this into a reconciliation thread.  Set version to 1.3, because I think it was at 1.2 before.  Currently pointing to 1.1, which was TOB's at time of copy.


You did take out the option to have an animation start at other than frame 0.  Gryff specifically asked for that.  Cannot remember the exact thread, but it is out there somewhere. 


Here are a series of diff snaps.  io_export_babylon.py is on the left, & io_tower_of_babel.py on the right. 


The FCurveAnimatable constructor comments out & forces auto animate to 0  - end (You did not delete get_first_frame() & get_last_frame).  Yes, I added it being conditional on my side.



Later in VectorAnimation constructor, you build up the frames the old way.



Finally, when TOB did both .babylon & .js / .ts, I was storing skeleton indices 2 different ways.  I added comments to that effect.  Wondering if each side should only do the version they write out, since armatures are kind of slow?










Link to comment
Share on other sites


The FCurveAnimatable constructor comments out & forces auto animate to 0  - end: You can revert to your version here. Wrong copy/paste

Later in VectorAnimation constructor, you build up the frames the old way. I think you can revert this one as well

Finally, when TOB did both .babylon & .js / .ts,: COuld you jsut keep the .babylon way for io_export_babylon.py?


Thank you for your appreciated help!

Link to comment
Share on other sites

Well, all changes are done for both, except that I thought I might test it.  Blend files are in extensions repository https://github.com/BabylonJS/Extensions/tree/master/Morph/Blender/blender-test/blender-in


First, I used camera_anim.blend to test that making autoanimate switchable in TOB, and that the animation reversion of official exporter back to TOB both worked.  They do.


I then used armature.blend to test each only builds the skeleton indices in the format which they actually write out.  That works.  Did notice that now the direction for the hemi light in this .blend has the wrong sign for the middle axis.  I did the hemi direction fix testing with voice_sync.blend, which is for MORPH 1.1, and not in the repository yet.  The light was very close to the ground & pointed horizontally, so this did not show up.


I cannot easily fix this myself, because I do not really know what that code does.  DK, Please look at issue with armature.blend.  Sandbox should work to see the light problem.  The skeleton is queued to walk in html, so it will just stand there.


When we get a final verdict on how to make the sign correct, make that change only and submit.



Link to comment
Share on other sites

Yes.  I do not know why, but in my tests I now get the stomach in light & chest dark, like light coming from below now. 


switched to 0,1,0, then I get what you get.  I am stumped.  Maybe those parens are needed.  I have to go. Will pick up tomorrow.

Link to comment
Share on other sites

I commit what I had & put in a pull request, version 1.3.0.  I could not reproduce your success with Blender 2.7.2b, the same .blend, and the direction line unmodified.  It could be my other changes, but I doubt it.


If I cannot establish a close delta of success to failure, I cannot fix this without knowing what this matrix_world, the setting of it's translation, and multipling by a 0,0,-1 vector is supposed to be doing.  Sorry.  Recommend making a version 1.3.1 that fixes it.

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...