As I am generating my terrain rather independently from my materials I encountered a problem with transparent materials being opaque rather than transparent.
To make them transparent i need to set the geometry’s Queue Bucket to Transparent.
[java]geom.setQueueBucket(Bucket.Transparent);[/java]
I need to set a Geometry parameter to make a Material transparent.
This is a rather odd design. I can see it having little impact in pregenerated scenes but as soon as geometry’s materials arn’t know at design time it becomes an undesired dependency; your geometry handling classes now have to know about transparency stuff.
(Yes I know you can dig down to reach and find your material’s alpha blend mode and work around the problem there but it’s a bit hacky to me and not entiry pure)
Wouldn’t the queue bucket state be better attached to the material in stead, along with all the other material affecting properties?
Its not really strange, the Geometry is the actual “visible object” in jME3 while the Material is just a template for how the Geometry should look. In jME2 Mesh, Geometry and Material were basically the same class!
A somewhat related question. Is there any sort of performance hit if you throw a bunch of objects into the transparent bucket, but they’re opaque for the majority of the time? Or would it be better to toss them into the non-transparent bucket (whichever that is, never actually done that hah), and switch them when you want to change their transparency?
~FlaH
normen said:
Its not really strange, the Geometry is the actual "visible object" in jME3 while the Material is just a template for how the Geometry should look. In jME2 Mesh, Geometry and Material were basically the same class!
But they're not the same class now (and they are seperated for good reason i'll assume). Also, I know nothing of JME2 and I think that can be an advantage, relying on what seems logical in the only world I know (JME3).
The way I see it, materials are just that. Glass is transparent. It should look transparent and if i put it in a mold (the Geometry) i get a glass teapot. I should not have to flip a switch on the mold to make the glass transparent.
I put some black plastic pellets in the mold and open it, i get a black plastic teapot.
No, you’re getting it wrong, the geometry is the thing that can look different, not the material. Its like you demand that the abstract thing “red” should have ripples.
Is it not the geometry that defines the shape of an object in space, and material that defines stuff like color, print and also translucency?
No, the Mesh defines the shape of the object, the Material is an information file for the appearance made through a shader and the Geometry is the visual object. This is not a discussion about your ideas but a simple fact, the translucency and render bucket etc. has to be set on the Geometry because that is the logical instance for a visual object.
To get things straight:
If I would want to define glass independent from colour, shape and degree of translucency - just the standard attributes every glass object shares - where would I define that? Because up until now I thought a Material would be the way to do it and now I’m a bit confused. 
There is no such thing as “glass” in OpenGL. Theres no objects, molecules or light rays, its all faked ^^
So to achieve faking glass you need to work with the geometry render bucket, some material parameters and a transparent texture maybe.
Ah well, okay. This is quite important for my next question:
I use simple 2D objects (a geometry with a quad and a texture with alpha channel) whose texture can be transparent (well, parts of it), to create a sprite (e.g. a player character). Now, when I use the Picture class, I don’t need to set the rootNode’s QueueBucket and CullHint, but as soon as I use my own Sprite class (which defines the QueueBucket.Gui and CullHint.Never for its Spatial) I have to set the Application-class’s rootNode’s QueueBucket and CullHint.
Also, when I set the Sprite-class’s QueueBucket to Transparent (which seemed like the normal thing to do) the object will not be shown on the screen, whereas when I use QueueBucket.Gui, it does (with the transparent areas being transparent). I think I have not understood the actual concepts fo the QueueBuckets and transparancy. Could you maybe shed a little light upon the whole thing, because what I’ve found about the QueueBucket isn’t enough to make me understand, why I would have to set the rootNode’s QueueBucket when I use my Sprite-Class but even the SimpleApplication-class does not set its rootNode’s QueueBucket.
You dont need to set it to the rootNode, no.
If I don’t, nothing will be rendered, as soon as I set the translation of the sprite to more than 5 or 6 (setLocalTranslation(10,0,0) for example). But as soon as I set the QueueBucket and CullHint on the rootNode, it works and I can move anything wherever I want to.
Edit: After further testing it seems that I only have to set the rootNode’s CullHint. Still, this probably means I have done something terribly wrong, I figure?
Sounds to me like the scene bounds aren’t being updated to include your sprite… so if root node isn’t in view then nothings gets drawn.
So maybe my Sprite class (or rather its shader) manipulates the position of my root node?
I don’t know what your sprite class does. But if you have to set Cull.Never on something to get it to consistently show up… that’s a sign that automatic culling is not working. Ergo, the bounds are not where they are supposed to be.
…this is common when creating custom nodes/meshes and not updating the bounding volume properly. If the children don’t update their own bounding volume right then their parents don’t, and their parents, and so on. Next thing you know, large parts of your scene go invisible at a slight camera movement.
Well, my camera never changes and as far as I know, the rootNode should automatically be in the view of the standard camera or am I missing something?
Does your object ever show up without Cull.Never? If not… then it is never in view as far as the camera is concerned. I was just stating the typical stale bounding volume symptom.
Getting wrapped around rootNode may be a wild goose chase. If your objects’ bounding volumes aren’t in the view frustum then they get culled… unless they are inheriting Cull.Never.
As above, I can tell you what’s happening… only your code knows why.
When I set the object’s and the rootNode’s CullHint to Never, it shows up.
And as long as I leave it at Position 0,0,0 it will show up fine. But as soon as I use Sprite.setPosition(>20,>20,0) (only two dimensional movement, because it’s a 2D-game) nothing is shown on screen, even objects I didn’t move (but are attached to the rootNode).
When this happens… see what the bounding volume for your objects and the root node are, etc…
Is this an orthogonal projection? I’ve never played with that so maybe it’s related.
Yeah, I found out if I set the frustrum of the camera to this.getCamera().setFrustum(0, 100, 0, 800, 600, 0); (near, far, left, right, top, bottom), the images are shown. There are still some errors when setting the image to a location too far up and to far away, but I guess I’ll never come to the point where I’ll set an image to 500something height and 60 depth. 
Of course, I still don’t know exactly what the camera actually does. As far as I know it’s some kind of aligning the camera, but tests with 3D Objects have proven this theory…faulty.