@zzuegg: as i good understand you will be able to to everything like now, but Blender users will have much easier export with all stuff like constrains, modifiers and more.
Most of these questions should be common sense:
@oxplay2 said:
Most of time i were watching blended iPad...
about topic:
I like how it is actually, but true is that for New Users it's hard to make assets work.
So for JME it is great idea.
still dont get something:
will SDK weight 30-40MB more, or builded Game? or rather more precision question, will only SDK need Blender integrated?
Only SDK. Once the object is converted from blender to j3o you don't need blender.
@oxplay2 said:
I understand main concept as: automatic update version of Blender + working ogre exporter for that version of Blender, so user only update SDK.
Or I guess direct import without going via ogre?
@oxplay2 said:
What about 3DS users? leave them with old traditional way?
and there will be also other problems like for example:
Users Question: i am using blender 2.65 and it donât work, why?
Dev Answer: Because SDK use Blender 2.63!
Which is the exact problem that is being faced all the time at the moment. Hopefully it would happen less with a known compatible version of blender bundled.
@oxplay2 said:
am i wrong? there can be such situations. Or not, when user will use SDK Blender...
Those situations happen all the time. The point of the SDK bundling is to make them happen less often.
@oxplay2 said:
What about 3DS users? leave them with old traditional way?
Maybe normen is planning on bundling 3DS too :P But I get your point. If Blender will be bundled, it might give away the message that jME is built for Blender. If Blender will be bundled, I suggest making a real tutorial on how to import from 3DS Max. If you give me the go-ahead, I can even do one myself. What do you think?
hmmm, ok, thank you @zarch for answers.
donât know if making only blend2j3o export will be good. sometime i can make ogre->j3o, but blend->j3o is impossible of some silly constrains problem.
@memonick said:
Maybe normen is planning on bundling 3DS too :P But I get your point. If Blender will be bundled, it might give away the message that jME is built for Blender. If Blender will be bundled, I suggest making a real tutorial on how to import from 3DS Max. If you give me the go-ahead, I can even do one myself. What do you think?
good im Blender user...
yes 100% right. if you can, then you should really make 3ds tutorials. go ahead! you don't need dev permission :)
There is only one valid OSS 3d editor 
And of course the engine and SDK can import models from any application just like before. But even 3ds users might benefit from Blender in the future, e.g. to convert / import models in other formats using the SDK.
So those that use Blender will have the version that works best with jME (while they can still install and use any version they want in their system) and those who donât will just benefit from where blender can help âin the backgroundâ.
Why not fork the orge exporter and only manage it with the engine development process? I think this is the easiest and least painful among all the other options.
Another thing is, sdk if not for pure artist right? Its for programmers and for artist who would use engine specific tools to get things done on the asset side. But, if you blend sdk with blender, thatâs just wrong.
- Why :? Do we look like python programmers with lots of time on our hands to you?
The point of using another format is having readymade exporters and stuff ^^
- Correct
- Nothing will be âblendedâ. Blender will be invisible for anyone who doesnât want to use it. But it can have two functions: a) serve as a modeling tool for those who want to use it because they donât have any and b) serve as a âswiss army knifeâ for model related problems, its scriptable as well. Blender wouldnât even have to be visible to convert models. Weâll have to accept that also in the future more people will be inclined to write a model importer for format X as a blender plugin and not a jME3 SDK one
@iamcreasy said:
Why not fork the orge exporter and only manage it with the engine development process? I think this is the easiest and least painful among all the other options.
??? It's not about what is compatible with JME as it is what is compatible with the 9 incompatible Blender versions. I'm not sure how "managing" the exporter solves this problem. Unless you mean that we'd somehow manage 9 different versions of the exporter and somehow autodetect which one to install in the random blender version that you are using... crossing fingers and hoping it's not the latest one that is incompatible with the other 9 versions.
Importing assets in the SDK right now is pretty lame. It's easily the weakest (and by a wide margin) part of the "whole JME experience". Anything that can smooth that out is better in my opinion.
1 Like
Im all for it!
Ease of use!
Maybe it would be a good thing to have a Download option âjMonkey SDKâ and âjMonkey Bundleâ with Blender.
We need the option to ânotâ install Blender.
Thinking of our system administrator at university here.
He doesnt like the âhuge bundle of unnecessary stuffâ installers like we know em from windows.
@zanval88 said:
Im all for it!
Ease of use!
Maybe it would be a good thing to have a Download option "jMonkey SDK" and "jMonkey Bundle" with Blender.
We need the option to "not" install Blender.
Thinking of our system administrator at university here.
He doesnt like the "huge bundle of unnecessary stuff" installers like we know em from windows.
IMO this thinking is not proper for this case. Developers said, that they could use Blender phyton scripting(to even convert other formats). Also that users could have write plugins in phyton, so, what if that plugins would be added to SDK and be necessary?
it's more than just bundle.
1 Like
Most animated models you can find are in FBX format⌠and thatâs on the rise since Unity uses it. I havenât found a working FBX importer for Blender (with animations that is). As such, Blender isnât really a major part of my JME workflow.
If there was some reliable way to get FBX and DAE animated meshes > Blender > JME3 Iâd strongly support this.
@monkeychops said:
Most animated models you can find are in FBX format... and that's on the rise since Unity uses it. I haven't found a working FBX importer for Blender (with animations that is). As such, Blender isn't really a major part of my JME workflow.
If there was some reliable way to get FBX and DAE animated meshes > Blender > JME3 I'd strongly support this.
Yes, honestly we were thinking about using FBX instead of Ogre as the main format but atm theres no official spec for the format, everybody just uses the headers to reverse engineer it. I am sure blender will support FBX better in the future and there is ways to import it already. The good thing about FBX is that most models are made for games and hence are game compatible (using only textures and bone animation, one mesh with a uv-mapped texture atlas etc).
@normen said:
Yes, honestly we were thinking about using FBX instead of Ogre as the main format but atm theres no official spec for the format, everybody just uses the headers to reverse engineer it.
I think supporting FBX natively would be a good move for JME3... it would make it much more accessible.
Model download sites and online stores will almost always offer the model in FBX format and as you say, it's usually game ready too.
@normen said:
I am sure blender will support FBX better in the future.
We've all been waiting years for this so far... people have half-implemented it and then it breaks with each new version as you say... blender is just moving too fast for that. I don't think we should pin our hopes on this.
There are lots of good mesh converts for various formats, I don't generally have any problem converting static models... its the animated ones where it becomes really tricky/problematic to get them into JME3.
The autodesk FBX converter (and SDK) can convert to DAE format I think, so perhaps that would be a good one to implement into JME?
@monkeychops said:
I think supporting FBX natively would be a good move for JME3... it would make it much more accessible.
Model download sites and online stores will almost always offer the model in FBX format and as you say, it's usually game ready too.
We've all been waiting years for this so far... people have half-implemented it and then it breaks with each new version as you say... blender is just moving too fast for that. I don't think we should pin our hopes on this.
There are lots of good mesh converts for various formats, I don't generally have any problem converting static models... its the animated ones where it becomes really tricky/problematic to get them into JME3.
The autodesk FBX converter (and SDK) can convert to DAE format I think, so perhaps that would be a good one to implement into JME?
Yeah, we can theorize about file formats to support all day long but it'd require more research on your side and another thread :) This blender thing has nothing to do with jME or its importers per se. Heres a link to a java JNI FBX loader interface that uses the autodesk loader etc. and you can try to make an importer for jME if you want. Afaik Blender 2.63 even has a working FBX importer by default.
The reason why FBX is/was not supported/shipped within blender is the that the license of FBX SDK is incompatible with the Blender GPL license, at least it was last time I researched this topic⌠another reason was that the blender core devs did not find any need for it themselves since they only use OSS and building a parser is less appealing than writing other fancy parts of the editor 
While creating the NBI installer with included JDK I also discovered a good way to bundle Blender
The NBI installer allows including other âproductsâ (apart from the main SDK app) to be installed with it. So now when the installers for the next release are built, the build automatically downloads blender in the correct version for each platform and includes it in the installer. It will be installed at (applications)/jmonkeyplatform/blender and be completely self-contained. A tool has been added in the SDK that allows launching blender, opening .blend files with it and even allows plugins to start python scripts with blender.
This of course opens up a lot of possibilities. Model importers from formats like 3ds come to mind. Or things like model checkers that check the animations and texturing of the model. Maybe someone comes up with a way to automatically create light maps.
@mifth: You said you were interested in looking into our options? Also into what scripts etc. could be bundled?
That would be so sweet then if we can include gimp and a free sound/music creator program. We will be set 1 download to rule them all!!
The image workflow and formats arenât particularly complicated though, I donât see the gain from packaging gimp (particularly for people like me who have photoshop!) whereas having a âknown to workâ and âstableâ blender version packaged and integrated is a big win.
Yep, I also think we have to strongly look at what we bundle. Blender makes sense because its a) very unstable in terms of features and compatibility and b) can be used for a lot of very specific mesh/model editing processes in the background, effectively becoming part of the SDK like the command line ogre converter. People have their workflows to create images, its mostly about the actual jME workflow
I added .blend template files with correctly prepared texture slots as well as added a simple blender animation example as well. Can be created via the âNew Fileâ menu, I also updated the blender docs on animation in the wiki a bit.
1 Like