I wondering how jME veterans would suggest combining 2D sprites with a 3D background. What I am looking to do is create a game similar to what you would in many tactical rpgs – a 3D tile based background, with 2D sprites always facing the user.
The 3D background can be rotated and the angle of view can be altered within bounds, with the 2D graphics rotating, to show the proper image to the user, with it.
When I was exploring Java3D the "Bulliten" class was suggested to me, but I never looked into it since I found jME before getting to the class descriptions. I would appreciate any suggestions on how others would implement the combination of the two.
You need to make a quad that has the character as it’s texture. You then attach this quad to a billboard node. This should give you the effect you want. There is a test that demonstrates how to do this( I am not sure what it is called).
Thanks Badmi. I found a few programs that used them – going to check them out tomorrow.
How would you suggest I handle animation on such an object? I have a walking animation, and various animations for certain actions. One suggest I got when asking around the Java3D list was to apply a texture to the node with all the images in it, and just update the UV coord as needed.
Is that still the best way, or is there a better way (or "just as good") with the jME architecture?
Another thought which may alter the "best solution" for animation is the way I hope to construct my sprites. They are actually made up of more then 1 image – with the head and body being two seperate images. This gives me the chance to provide a degree of customization for the user; nothing super advanced, but just a touch.
So each time the sprite turns to a new angle (say, facing forward to facing to the back), I would need to update the head image and the body image. Would dynamically updating the image file being used for the texture (with there being … say … 100 sprites on screen) be too much?
The use of one image containing all sprite images for animation is pretty common and well proven. I’d go with that.
As far as jME implementation, I just want to add to what’s been said by saying you don’t actually need to use billboards if the sprite does not change size (ie, stays in the same 2d plane.) You can simply use the ortho queue and a regular Quad.
Thanks renanse. I’ll look up more information on ortho queue and how it works. The sprites shouldn’t change planes, I don’t think I am wanting to do anything so complicated as to require them to do so.
For textures, I’d still like to use multiple files to store the pieces of my overall sprite (head, body, weapon). Is updating the image data used to draw the sprite the only/best way to do, or is there a trick I can use? Is there a draw() function I can override, in which I can check the direction of the sprite and update the texture data?
Thanks again all.
You could potentially extend Quad and make a Sprite class. Then you could override updateWorldData (call the super though) and make the changes there. I would encourage you to use a method that preloads the images in some way, whether that be in a single file or by creating and applying multiple Texture objects, etc. because creating textures during animation will simply be too expensive. Using a single image simply means storing each frame of animation in a grid pattern in one image… you could do one image for all the head animations, one for body and one for weapon… Then you just manipulate the texture coordinates to point to a single square on the grid. You’d want to use one quad for Body, one for head and one for weapon. Then you can use z-order to have the head and weapon appear over the body. Make sure the images have a transparent background for blending.
Ah... I hadn't even thought about that. I had "single sprite, single quad" stuck in my head. Curse this tunnel vision! :)
So, I'm looking at a Sprite function with multiple quads to hold the different pieces-parts. Would I want to extend Node in this case, or would it be better to handle the alignment of all the quads in a different way?
Also, don’t forget about SwitchNode, this can contain multiple nodes that can be switched out instantly based on certain criteria. Right now it’s used for discrete level of detail, but can be used for other things. You can then switch sprites as needed.
So many cool things! Someone needs to write a book on jME!
Thanks Mojomonk. I’ll take a look at it too.
Someone needs to write a book on jME!
Cep is certainly working on it :)
Go Cep go! I’ll be happy to help with any feedback you need from 3D ignorant people.
Almost 100 pages of documentation in the Starter.pdf guide ! whew