Hi Monkeys.
Coming from the same angle as the lately discussed inclusion of the JDK in the jMonkeyEngine SDK heres the next, even madder step in delivering a one-download game development package 
As the title suggests, we are thinking about bundling a version of Blender with the SDK :o
Now, most of you noticed that asset import issues are among the most severe for beginners and advanced users alike which has various reasons. First of all āsome modelā != āgame compatible modelā and then theres one way to do it right in Blender and about 100 to do it wrong. If it was just like that, normal documentation would help. I mean we all know creating a game isnāt exactly childs play and can be demanding to your general IT skills 
But the one part that completely kicks us off the road to an effective asset workflow isā¦ Blender updates 
Every version of Blender seems to break either the ogre exporter or the blender importerā¦ Or completely changes the way some effect or setup can be achieved (animation, texturing, baking etc). Personally I was using 2.49 for very long because the import workflow just workedā¦
So, the idea is
a) inclusion of Blender in the SDK download, it would not be installed in the system but live in the SDK folder, complete with preinstalled ogre export script etc.
b) tighter integration of Blender in the SDK in the form of āopen withā menu entries and a button to āLaunch Blenderā
c) updates similar to normal SDK updates for that Blender version after they have been checked for compatibility, including the checked and updated ogre exporters etc.
d) in the future use Blender as a ācommand line conversion toolā in the background to widen the support for model formats (the same way the SDK supports binary ogre models as opposed to the engine)
e) addition of good scripts and things for game development (ideas?)
Of course there would be an option to use a Blender version installed somewhere in the system instead of the internal one for those who want to use/test other/newer versions of blender. Think a checkbox and a path to the executable.
Whaddyāall think? 
Cheers,
Normen
Edit: Btw the download would grow about 30MB.
do it!! asset importing has been probably the biggest issue I have had with jME. Although it is a lot better now, i still get issues, one way or another, and have to fork between different formats and settings until one works.
Simplifying this, with a solid working bug free asset flow, even if it doesnāt use the latest versions versions of software would be huge imo
As a matter of taste I donāt like the bundling thing at all, I already have a JDK and Blender, why would I want another of each.
However, for all the reasons listed this would be really good so Iāll +1 and thumbs up. Like the man said, do it!
Iād rather like a bundled artist instead, one that can make my modelsā¦ 
Yeah, importing models is one of the weak spots of the engine. If that can be offloaded to blender it would be good. Thumbs up, as long as itās an opt in feature
I like itā¦ what version of Blender? Which ogre exporter? Will there be an option for which?
@t0neg0d said:
I like it.... what version of Blender? Which ogre exporter? Will there be an option for which?
The one that works ^^ So right now that would probably be the latest version (2.63?) of blender as afaik it works with nightly and some ogre exporter..
Blender 2.64RC2 + ogreExporter 0.58ā¦ But I often use blender svn versionā¦ i hope it will be ease to switch to my custom blender buildā¦
Also latest blender builds are here: http://builder.blender.org/download/
Weāll certainly not go with pre-elease or svn versions.
Blender 2.64 will be released in 2-3 weeksā¦
Iām finding the built in blender importer works well - I never did get the ogre pipeline working (although I stopped trying once I found the direct import and that worked).
I think the idea is a decent one, so long as there is no problem with the blender licenses that might come from bundling it?
Iām wondering if itās worth doing a netbeans-like set of options when downloading the SDK - so people can choose what gets bundled with it. For only 30MB though I donāt think it is really worth worying about that complexity.
@zarch said:
I think the idea is a decent one, so long as there is no problem with the blender licenses that might come from bundling it?
We could even name it the "jMonkeyEngine mesh editor" ;)
From the blender.org site:
Btw, this would in no way replace any functionality of the SDK as the frontend to edit actual jME data is needed in any case.
thats great and all but will it blend?
http://www.youtube.com/watch?v=lAl28d6tbko
and i suggest we keep it called Blender to avoid confusion :)
@mifth said:
Blender 2.64 will be released in 2-3 weeks...
hehehe that's spot on the problem....and 2.65 will be release in 2 months....and 2.66 in 3 months...
@Kealthas made a lot of progress on loading things from 2.63, there is a new ogre exporter that seems to work. 2.63 brings B-mesh editing that is a lot more straight forward than previous mesh editing...I vote for blender 2.63
Of course...future release of JME 3 SDK will be bundled with an updated version of Blender +ogre exporter. The idea is not to stuck blender in one version for ever, but to control what version is "compliant" with JME.
I use Blender and I use jME. But I am fine with it not being integrated.
To be frank I use jME because of how easy and fast it is to get good results. Not because of the SDK, but because it is well structured and well documented - and because the community provides excellent support.
@nihal said:
I use Blender and I use jME. But I am fine with it not being integrated.
To be frank I use jME because of how easy and fast it is to get good results. Not because of the SDK, but because it is well structured and well documented - and because the community provides excellent support.
If you don't use the SDK then this isn't relevant to you anyway ;) I like to set up a development environment with one installer instead of over a few months as in jME2 times ^^
@normen said:
If you don't use the SDK then this isn't relevant to you anyway ;) I like to set up a development environment with one installer instead of over a few months as in jME2 times ^^
True, I cannot argue against that. My only point was that from my point of view, time could be better spend on extending the capabilities to the engine itself.
I will not argue that this cannot benefit anyone else though, I think it could be a big help for those struggling with the interface between Blender and jME and various other issues. I do appreciate the massive effort that so many of you are putting into this project, makes my life a lot easier. Just giving you my perspective. :)
@nihal said:
True, I cannot argue against that. My only point was that from my point of view, time could be better spend on extending the capabilities to the engine itself.
Devlopment time doesn't work like that, especially not in an OSS project. And I bet SDK users beg to differ that its just about the engine :) The point of the SDK is to fill in the huge parts of game development that are not just about code or art and the model workflow is a big part of that. And acually its not much work integrating blender like this.
As long as that will not lead to a dead ogre importer, go for it.
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?
I understand main concept as: automatic update version of Blender + working ogre exporter for that version of Blender, so user only update SDK.
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!
am i wrong? there can be such situations. Or not, when user will use SDK Blender...
I see that the asset import pipeline is certainly important and i not have an large enough overview of the different format out there. I can understand that importing the native blender format will cause problems with every update.
The question for me is why sticking with that format? Why not use one of the more stable formats? FXB, or 3ds? I would simply go for a format nearly every serious 3d modelling program is able to export toā¦ (somewhere in this repo: GitHub - OpenEndedGroup/Field: A development environment for art should be some lib to load fxb)ā¦
In the long term that might be less work that updating the pipeline each time a new version of blender getās published.
Just a few toughtsā¦