Your image is inscrutably small. I did figure it out because I happen to have blender open.
Truth is this is the first time I’ve run Blender 2.8 and I still have no idea where anything is.
Can you tell me more about this?
File → Link does this. File → Append to make a copy.
Your image is inscrutably small. I did figure it out because I happen to have blender open.
Truth is this is the first time I’ve run Blender 2.8 and I still have no idea where anything is.
this third icon is like JME game real-time PBR render. nothing advanced 
You just need use principled BSDF in Blender as material to make it work properly, nothing more
--------------because there is background process
Can you tell me more about this?
well, i asked wrong question.
the more proper question would be:
So can i just execute some Java method from groovy directly? (like i use in game to adjust character model)
And do it execute each “ANY scene change”?
Whenever the model is reloaded, the scripts are run again… so you get a freshly converted model each time.
Yeah, as said… I figured it out.
Looks like JME still doesn’t handle emissive color on its own yet:
https://imgur.com/Ud5aXdJ.png
Nehon and I talked about this a long time ago. You can only set the emissive color with a texture.
Edit: I tell you what, though… being able to tweak something and see it JME immediately is HUGE.
3 Likes
nice, it also could help to adjust PBR look same as in Blender.
you have emissive in this materials?
Blender always had “hidden light” kind of, i think its related to make user better see model.
please note Blender in
- third icon(Eevee rendering) dont take “light” as count. But it show PBR result alike.
- in forth icon it use light, but no reflection(like no eevee-PBR), because it need to be set as skybox (not virtual one)
in Render TAB, you can change from Eevee to old Cycles, it will be same as 2.79 preview.
Yeah, the spheres are ‘glowing’ with emissive.
Longstanding PBR issue… not a big deal, though. (edit: I actually fixed it in my Spacebugs fork so that my power cubes could have glowing+flickering lights of different colors.)
ah ok, i just thought you was suprised it just dont look same 
I think they would look identical if I had the same lighting setup and JME supported emissive. (Also, my probe is a little different than blender’s… I just found a close one.)
yes i think the same, should be ok if not emission,
never tried see if forth preview in Blender with same probe and lights will give same result
edit: also nice thing to let you see:
- edit model Bump texture in third preview option, see how nice to edit (you see immidietly result, not like in cycles need to wait)
well, thats how we do “normal maps” we bake them from bump map that can be easly made with Blender Eevee preview. No need high/low poly models for normalmaps.
But it also require proper tool and know that Bump map require more colors/etc to make it look good. but if you know how to make bump high quality, then normalmap is very easy to be done.
Im not sure how JME Material trully look like when exporting with just a Bump map(is this converted somehow or not). But if someone would tell if its optimal, would not even need convert.
when now i thought, i got a question related to PBR export:
-
is Bump map exported into JME as Bump map, or it somehow convert it to normalmap?
(i dont see bumpmap in PBR material in SDK) -
if as Bump, then is this somehow able make build-in converter to normalmap?
(because currently we use Blender “tool file” to bake it from bump)
PBR supports separate bump and normal maps. It will not generate a normal map for you.
I have no idea with the gltf importer does with a blender bump map “by default”… but I’ve seen many sketchfab models import correctly that seem to have bump and normal maps.
1 Like
Incidentally, I’ve checked in my “work in progress” with respect to the JmecNode:
If you check out the project and “gradle install” it then you can play with it locally.
…and/or go to the examples/node-demo directly and use gradle run to play with the sample.
1 Like
I have no idea with the gltf importer does with a blender bump map “by default”… but I’ve seen many sketchfab models import correctly that seem to have bump and normal maps.
all is fine, i just thought if there could be simplify for our model create workflow.
If you check out the project and “gradle install” it then you can play with it locally.
sure, will use it when creating complex models. (like character / its equipment).
Its what i was looking for when were doing complex models so thanks a lot!
1 Like
So in my “How WOULD I make a level in Blender quest?” I’ve discovered some things.
Best way is to have a file or files that act as a library of objects. Online recommendation is to use collections to organize them (formerly groups). So you could have a library of trees or dungeon parts or ship parts or whatever.
Then use File-Link to link those objects into your scene.
Provided both for any fellow blender-noobs trying to follow along as well as making sure we’re all on the same page:
For example, in my test scene, I grabbed that funny stack of shapes (let’s call it a lamp for lack of a better name)… then I made a collection from that and then saved the file as “test-collection”
I opened a new file, then went to File->Link, selected test-collection and then navigated to the collection I created above. Sure enough, this sucks in the lamp into my scene and it acts like one object.
Whether I File-Link the same collection again, duplicate the object, or “duplicate linked” the objects, they are still the same shared source object. Kind of cool.
When exporting the gltf, these are also all shared in the gltf and special transform instances are created (possibly detectable).
HOWEVER JME’s GLTF loader does not handle these correctly. I’m still tracking down what the issue might be… but I end up with only two of the “lamps” and they aren’t in the right place. It’s weird because if node-level instancing wasn’t working, I’d expect only one to work.
Anyway, given that these instances all have the same child list, it might be possible to write a post-processing script that would find them all and export them as separate models… I’d need to modify Jmec to do something similar to what it does for generated materials so that you could mark a subgraph for separate saving.
…but this does give us hope to have a GLTF-based asset path for using Blender as a level editor, assuming we get the bugs fixed and add that feature.
5 Likes
I’ve narrowed it down to a couple bugs in Blender’s GLTF exporter.
Bug 1 is that the linked objects export without transforms which is why the pile on top of each other (no surprise).
Bug 2 is that sometimes the children get confused and one instance will refer to another instance as one of its children… this causing duplicate children.
Edit: not even sure the best way to report such things, actually.
Edit: bug 3, they also sometimes lose materials which may or may not be related to the causes of the other bugs… hard to say.
2 Likes
The Khronos Group maintains both the glTF spec and blender plugin, which can be found here:
They are very responsive on github issues.
i confirm, i made like 2-3 issues there, and they were very responsive.
Yeah, agree. I also prefer an in-game editor for scene creation. Using a bunch of groovy scripts to do automatic object plotting I am able to make scenes quicker than doing it in Blender.
Finally by attaching the TranslationWidgetState I am able to easily grab and move objects in the scene just like Blender.
For the record, it seems like there are already issues covering some of this:
Not sure when they will be taken care of.
In the mean time, I will try to add some features to JMEC to allow for the saving off of separate sections of the scene graph similar to how generated materials work. This will at least set us up for the case where these bugs are fixed and we want to end up with multiple j3os.
1 Like