It’s been a while since I have posted or developed any new game and the last couple of days I have been pondering with an idea of making my game levels in Blender3D.
But first of let me explain my previous way of work:
Normally, like most I think I would create my models and assets in Blender3D or some 3D modeling tool and use that in my game by either build it up programmatically or slapping the level together with jME scene editor.
And then add all sorts of controls or states to this scene.
So now my thinking goes in the direction of, why not build the complete scene or level in Blender3D and add certain properties to these object in blender. Then when loading that level or scene in jME we make use of a SceneGraphVisitor which will look for specific properties on spatial objects and then add the behavior in that way. (example: physics, movements, rotation, trap controls, etc)
So my discussion actually would be does any one else do this type of level design or am I making more work for myself?
Eventually I switched to blender. It’s just too much work re-creating the interface and 3d environment controls that Blender has, and for some tasks they are necessary. Placing models in a scene was one of those tasks. My positioning tools in my editor where okay, but still nothing like Blender - being able to snap a model into a surface for example.
Eventually I just ended up writing scripts in python to export my blender data (custom properties) into a txt that I can import. Really smooth process now.
Ideally I would have liked to use python to create a custom UI in Blender for all sorts of properties, but tbh it was a bit of a nightmare, not overly well documented and I can’t say I like python, so I took the easiest option of just using the custom property box.
Thanks for the response @JESTERRRRRR.
That is basically my thought on the process as well.
As a P.O.C. I have started with a basic 2d game where I make my level in Blender and make use of the custom properties in blender to add behavior. So far so good, but we will see how far I can stretch this.
Tbh the blender option is much faster like you mentioned.
If you want to make each location completely unique, you can do it in Blender. So for example each cave will be different, with its own special textures, shape, decorations.
If you want to have unique premade locations but composed with chunks - choose scene editor, load smaller assets and place them on your location. It is good for towns, villages etc.
If you need to create your scene dynamically or to not rely on scene editor, because you have your own - create chunks in Blender and place them by code. Just like I did in Skullstone: every wall, every torch, door, trapdoor, decoration placed on map in 2d editor and every item (sword, potion) have their own x:y locations in 2d world + directions + states + few other params. All of these params are ‘translated’ to 3d transformation and applied to spatials.
So basically it comes down to what type of game you make.
I will endeavor on the blender road for a while and see what that can bring to the table.
The idea of having an advanced tool such as blender to design levels is actually very nice.
In blender we can link from a .blend file, which is similar to AssetLinkNode in jme.
But non of jme blender importers support this. (I also had a discussion with @david_bernard_31 regarding support for linked assets in xbuf-blender exporter).
So one solution is to create your scene in blender by putting chunks together and when exporting them, you only export nodes without exporting mesh. Then when loading it in jme, load the relevant j3o chunks and attach them to related nodes by name.
I was using this approach before the existence of Lemur Drag and Drop framework. After I take a look at new DragAndDropDemoState
a whole bunch of new ideas come to me.
I think with the ideas similar to StackControl and GridControl I can do an in game entity designer.
So we can drag and drop pieces together and create a verity of houses (by attaching floor tiles, wall tiles, roof tiles, …) and interiors then save them as AssetLinkNode which will be huge save on disk. (In your example the ContainerNode extends Node, I am going to extend it from AssetLinkNode).
The second most important benefit is we can do some smart collision shape generation while we adding the pieces.
The next very important benefit is, players also can do in game design. ( Has it’s own use case).
and so on… .
Sorry for talking so much, just wanted to share my idea.
Hey @pspeed, what will happen if I link 100 of the same trees in a scene in jME?
Surely they will be handled as separate objects and meshes when send to the GPU?
In JME, many Geometries can share the same Mesh data. By default if you clone a Geometry (not animated) then the mesh data is shared… 100 trees with the same mesh is only 1 mesh in memory and only 1 mesh sent to the GPU, etc…
That’s the case If I’m correct. However, In my case I did an intermediate software that loads the full scenes and checks their spatials for information about how it must be parsed. I give to each object in blender an Id (so each time it is placed in scene this id is copied to the new object) and then, when parsing, I just generate one j3o for that object and a “scene file” that says where is every item in the scene. I do the same thing with all materials and textures (for those I just compare them to see if they are equals). Well, the point of all this is that the scenes can be fully constructed in blender and then with that piece of software, generate the scene that is going to be used in-game.
This way, the scene composer is already there and all-powerful (only tried with Blender currently but if jme3 can load it and it can translate “user-data” from it, then any program is valid).
So, I would say: yes, Blender is a viable solution for level design.
I wonder if for someone just coming at this problem if it would just be easier to submit a patch to xbuff rather than do all of the import legwork, reinventing your wheel, and so on. (remembering to assign IDs in blender, etc.)
Well… when I started to do it I didn’t know about xbuff (just about ogre-xml)… then it started like another stuff, it changed, again, and again… But yes, maybe you are right (however, the ID thing isn’t that bad as I use it to generate the game logic too and all has it logic-sense).
Yeah, you’ve already got your solution. I was more referring to someone starting now that can’t use your solution. In order for blender to be “viable” they have a lot of work left to do. If they make xbuff work better then potentially everyone benefits at once.
Oh!, of course. If I had to start now I’ll go for x-buf, without any doubt. However:
I have the impression that you are considering here that blender is separated from xbuf, when xbuf’s target isn’t to be a composer per-sé, but an intermediate format, so it needs a third application that do it (in this case, blender), doesn’t it?
Yes, that’s why I said in order for “Blender to be viable”. Blender by itself, without your extensive import work, is not really viable for many types of scenes… unless xbuff is fixed to properly export shared data as shared somehow.
I wanted to just say a few things about my use case. Everything 3d is exported separately, I export “level model” being the walls and floors if you like, then things like “props” that I place are exported, all individually.
When using blender as a level editor after all 3d stuff is exporter I can tag things, for example I tag 3d models in my scene as “prop”. Then when I import my txt in java it loads them with the assetmanager, so you get a clone with a shared mesh.
One of the most useful things for me is exporting triggers
These boxes are all on a separate layer in blender and all trigger something else by name. They can make a bit of code run or whatever I want. Setting this up in java was pretty trivial and so far it’s been very flexible, but I just wanted to emphasize that this I’m using this export bit as a pure level editor really, no 3d stuff is exported in this “phase”.
edit: Just saw [quote=“pspeed, post:19, topic:38010”]
Blender by itself, without your extensive import work, is not really viable for many types of scenes.
[/quote]
So yes I too am using it with some extensive import work. Still recommend it as it’s worked beautifully for me.
