HottBJ v. 0.4a Released

hottbj-0.4a.zip



This release improves and extends support for Blender Materials and Textures.  See the release notes for details.  I have not updated the docs, other than the release notes; nor have I updated the HottBJ Tutorials which still list some constraints and limitations which have been eliminated.  Docs will be updated for the next public release.



These extensions satisfy all of my original goals for HottBJ, excepting conversion of Blender Mesh and Object references/links to jME SharedMesh/Nodes, and that isn’t a priority for me now.  Therefore, after the 0.4 series will come the 1.0 series.  I’d like to get it bundled with the next Blender point release, if I can find somebody helpful on the Blender side.

Good stuff! I'll try this out, tonight.

Thank's very much for your importer!



Some questions:

Do you plan supporting Normal and/or Bump maps?

Would be really nice, but if you don't plan or not in the near future,

I will just make this on the jME side programmatically…



Normal map + Bump map, are just too great to miss ;]

So I'll looking forward to easily export them from Blender -to> jME

tim8dev said:

Thank's very much for your importer!

Some questions:
Do you plan supporting Normal and/or Bump maps?
Would be really nice, but if you don't plan or not in the near future,
I will just make this on the jME side programmatically..

Normal map + Bump map, are just too great to miss ;]
So I'll looking forward to easily export them from Blender -to> jME


Yes.  If you could PM me exactly what settings in Blender correspond to what settings in jME, at least for the most common use cases, that would accelerate things.

In the tests there are two versions of normalmapping (jmetest.effect.TestBumpMapping and jmetest.renderer.loader.TestNormalMap). Don't know if it explained the right way but the first one is a opengl-based combinating the normalmap-texture via dot3-calculation to the colormap and the second one is using a shader. This shader seems to have the disadvantage that you cant scale the texture so wrapping is not working.



Maybe ncomp can help out here as he seems to have a clue about it! :smiley: And he seems to have a shader-version that is capable of wrapping:



http://www.jmonkeyengine.com/forum/index.php?topic=12193.msg91111#msg91111












Hi Blaine!

First of all, thanks for your create efforts making the art-pipeline easier for us jmonkeys!



I've been trying out your modeler at http://pub.admc.com/modeler/modeler.jnlp and I ran into a few problems.



First of all when I hit TAB a few times, the app sometimes just freezes.



Also, hitting tab doesn't update the animal widget. I have to rightmouse-click the model in order to update the animal widget. Clicking on the a node in the SceneTreeWidget also doesnt update the animal widget.



Finally, when trying to mount an weapon (Im following your 0.3c release thread), the app also hangs after a short time. I've downloaded your xml files locally, which speeds up importing models but doesnt make a difference to the "freezing"-problem.



Im running windows XP SP 3 with the latest JRE (update 17). 3GB RAM, Geforce 7800GT, AMD X2 3800+

Thanks!



Edit: tried about everything but the modeler keeps freezing after I do a few things. (importing, rotating, scaling etc.)

Re: Darklord



Thanks for the reports.  I'll investigate and reply back here within a couple days.



For future problem reports, please open new topics in the appropriate forums, unless the problem is specific (and new) to the release being announced.  If you want me to be aware of it, PM me after posting.

blaine said:

Re: Darklord

Thanks for the reports.  I'll investigate and reply back here within a couple days.

For future problem reports, please open new topics in the appropriate forums, unless the problem is specific (and new) to the release being announced.  If you want me to be aware of it, PM me after posting.


You're welcome!
Is this "appropriate forum" a forum you host or do you want me to create topics in this forum?

Thanks!
Darklord said:

Is this "appropriate forum" a forum you host or do you want me to create topics in this forum?
...


Among the forums listed here.  Understood that the denotation of "forum" is very ambiguous.
Darklord said:

First of all when I hit TAB a few times, the app sometimes just freezes.


I'm unable to reproduce after hitting TAB hundreds of times.  But tab behavior is entirely different depending on whether you are tabbing with 3D scene focus, in a HUD form, or somewhere in between.  Please try to narrow to a minimal repeatable test case.


Also, hitting tab doesn't update the animal widget. I have to rightmouse-click the model in order to update the animal widget. Clicking on the a node in the SceneTreeWidget also doesnt update the animal widget.

You have multiple Animals loaded in your scene?  The Animal Widget is there to work with the last ANIMAL object that was selected.  If you TAB to anything that is not an animal, that should not change the AnimalWidget at all, since you have done nothing to change the Animal which is the object of that widget.

The Animal widget should only update when you TAB to a new animal object, whereas the Spatial Properties widget should update as you TAB from Spatial to Spatial.


Finally, when trying to mount an weapon (Im following your 0.3c release thread), the app also hangs after a short time. I've downloaded your xml files locally, which speeds up importing models but doesnt make a difference to the "freezing"-problem.

Im running windows XP SP 3 with the latest JRE (update 17). 3GB RAM, Geforce 7800GT, AMD X2 3800+
Thanks!

Edit: tried about everything but the modeler keeps freezing after I do a few things. (importing, rotating, scaling etc.)


I'm unable to reproduce.  I have several large models loaded and can do whatever I want to with them.  My system is very similar to yours but I'm running Linux now.

Please try to narrow the conditions.  Does it only happen when a specific model is loaded, whan any Animal model is loaded, when any model at all is loaded?

I'm going to reboot to XP now to try to reproduce.  If you get back with more specifics, I'll have other people try to reproduce on Windows too.

I can reproduce the "stuck" problem on Windows.



DL:  It would be extremely useful, and greatly speed up getting this fixed, if you could confirm or reject this tentative claim:  The problem only occurs if the Settings, Spaitlal Props, Anima Props, or Scene Tree widget has been displayed.  Please try to reproduce the problem without opening any of those widgets at all.  You can TAB and SHIFT+TAB to cycle through the Spatials, and you can use SHIFT+F1 to make Modeler load a lot of polies.  You can ALT+fi com.admc.sample.PsychedelicSphere("ps") and SHIFT+F2 and SHIFT+F3 to make it do more work.  If you accidentally open a Settings or SHIFT+F6/7/8 internal frame, please exit and start the test over.  (My testing shows that the problem persists even after I minimize these windows).



If you can verify that claim, then it's very likely an OpenGL and/or EDT thread contention issue.  I recently switched to use the Java2D pipeline and JOGL sets up the threads completely differently in that mode; and in a way that is much more platform-sensitive.  That's the (high!) cost for improved performance (eventually).



If you confirm the claim and want to help further, please test with only one of the questionable widgets opened (making sure to not open any of the others for the entire session).  Then report back which widgets are causing the problems.

Hello Blaine,


blaine said:

I can reproduce the "stuck" problem on Windows.

DL:  It would be extremely useful, and greatly speed up getting this fixed, if you could confirm or reject this tentative claim:  The problem only occurs if the Settings, Spaitlal Props, Anima Props, or Scene Tree widget has been displayed.  Please try to reproduce the problem without opening any of those widgets at all.  You can TAB and SHIFT+TAB to cycle through the Spatials, and you can use SHIFT+F1 to make Modeler load a lot of polies.  You can ALT+fi com.admc.sample.PsychedelicSphere("ps") and SHIFT+F2 and SHIFT+F3 to make it do more work.  If you accidentally open a Settings or SHIFT+F6/7/8 internal frame, please exit and start the test over.  (My testing shows that the problem persists even after I minimize these windows).


Executed and the app did not freeze. Meaning you're defiantly thinking in the right direction.

blaine said:

If you can verify that claim, then it's very likely an OpenGL and/or EDT thread contention issue.  I recently switched to use the Java2D pipeline and JOGL sets up the threads completely differently in that mode; and in a way that is much more platform-sensitive.  That's the (high!) cost for improved performance (eventually).

If you confirm the claim and want to help further, please test with only one of the questionable widgets opened (making sure to not open any of the others for the entire session).  Then report back which widgets are causing the problems.


After conduction the test above and adding all functionality you mentioned the following widgets gave a freeze:

Spatial Properties widget: freeze
Note:The widget was active and I tabbed inside the widget. While I tabbed inside the widget the cursor moved but spatial selection was also swapping.. as if the tab button holds 2 functions.

Scene Tree widget: not freezing
Note: Same situation here. I'm tabbing inside the widget and spatial selection is switching as well. This time however nothing is freezing. Tabbing without the widget selected gives the same results.

Animal Tree widget: not freezing
Note: Same situation here. I'm tabbing inside the widget and spatial selection is switching as well. This time however nothing is freezing. Tabbing without the widget selected gives the same results.

Another note, whenever I pulled up the Spatial Properties Widget and the Animal Tree Widget I noticed a blue flickering screen "pop-up" and the terrain's colour would turn grey. The scene tree didn't give me those results.

If you ask me, I think Spatial and Property are both at the root of the problem. But thats just speculating. If I can help you out further let me know. In the meantime i'll use your tool on a linux VM box.


Edit: I also received some kind of Queueflush exception when letting the client open for a longer while.



Excellent.  Very useful.


Darklord said:

... In the meantime i'll use your tool on a linux VM box.

You don't have to do that.  Use this non-pipeline-mode launcher:  http://pub.admc.com/modeler/modeler-py.jnlp?pipeline=false.  It will run slower than with pipelining, but you won't hit these problems.

Darklord said:

Edit: I also received some kind of Queueflush exception when letting the client open for a longer while.


Please email or PM me entire contents of the Java Console for that run, or at least the Exception stack trace.

BTW, I've fixed the long-standing, annoying, flickering rotation-value bug.
blaine said:

You don't have to do that.  Just add HTTP param setting of pipeline=false to your launch URL.  If your launch URL already has a ?, then append "&pipeline=false"; if your launch URL has no ?, then append "?pipeline=false".  It will run slower than with pipelining, but you won't hit these problems.


I haven't gotten the slightest clue what you mean. Im using the url from your site.
http://pub.admc.com/modeler/modeler.jnlp

What steps do I have to take to disable "pipelining"? Add "&pipeline=false" behind that url?

blaine said:

Please email or PM me entire contents of the Java Console for that run, or at least the Exception stack trace.

BTW, I've fixed the long-standing, annoying, flickering rotation-value bug.


Great job.
I'll try to reproduce it but I'm not sure when it appeared. I saw it a fraction of a second after I closed the app. The app had been running for 30 mins or so.

Thread contentions identified.



I definitely can and must fix these.  Unfortunately, it will require pretty much rewriting every widget that Modeler uses.  I knew when I changed to pipeline mode how the threading design differs, but I didn't remember how much I depended upon the JOGL threading implementation as documented in the main JOGL intro doc.  It's surprising how radically they deviated from that implementation for Java2D pipeline mode, with barely a mention of the Threading change, and no warning about the drastic effects this must have on any non-trivial app.



ETA 2 days.

Darklord said:

...
I haven't gotten the slightest clue what you mean. Im using the url from your site.
http://pub.admc.com/modeler/modeler.jnlp

What steps do I have to take to disable "pipelining"? Add "&pipeline=false" behind that url?


yes


blaine said:

Please email or PM me entire contents of the Java Console for that run, or at least the Exception stack trace...


...
I'll try to reproduce it but I'm not sure when it appeared. I saw it a fraction of a second after I closed the app. The app had been running for 30 mins or so.


As the thread you indicate is the OpenGL thread (as it appears with pipeline mode), and I'm rewriting most of that, I withdraw my request for the log/trace.
blaine said:

Darklord said:

...
I haven't gotten the slightest clue what you mean. Im using the url from your site.
http://pub.admc.com/modeler/modeler.jnlp

What steps do I have to take to disable "pipelining"? Add "&pipeline=false" behind that url?


yes


I was asking because this explicitly because using http://pub.admc.com/modeler/modeler.jnlp&pipeline=false still makes the app freeze.
Darklord said:

...
I was asking because this explicitly because using http://pub.admc.com/modeler/modeler.jnlp&pipeline=false still makes the app freeze.


Just use this launcher:  http://pub.admc.com/modeler/modeler-py.jnlp?pipeline=false

And verify that the Java Console reports non-pipeline mode.
blaine said:

Darklord said:

...
I was asking because this explicitly because using http://pub.admc.com/modeler/modeler.jnlp&pipeline=false still makes the app freeze.


Just use this launcher:  http://pub.admc.com/modeler/modeler-py.jnlp?pipeline=false

And verify that the Java Console reports non-pipeline mode.



Nov 19, 2009 4:43:32 PM com.admc.agf.e <init>
INFO: No Java2D pipeline


Confirmed, thanks!

Edit: Another "unwanted" feature... Not sure if you already were aware but ill report it anyhow... Whenever I use your advanced.jme-xml model and mount an axe, the model gets the axe. When I open the scene widget and the animal widget, and remove the axe the scene widget doesn't (logically) update. However, When I press "reload" the app crashes stating "axe.xml could not be found!".

JOGL developers, please see this JOGL forum post.  That issue is greatly complicating my goal to do every task in the correct Thread for that task.  It would both complicate updates and distributions, and possibly add days to the fix time, if I have to override JOGL classes.



UPDATE:  Resolved (as much as possible).  My problems are consequences of work-arounds built into JOGL due to the many thread contention inadequacies in JOGL 1.x.  The long-term solution is to upgrade to JOGL 2.0, which will allow me to code according to best practices, and also minimize thread contention for maximum performance.  In the short term I will have to runtime-toggle threads based on JOGL’s runtime decision of what it pretends to the the OpenGL thread, because converting all of the jME classes to JOGL 2.0 is not a short-term task (and also commits me to long-term merging responsibilities).