Is the following strategy possible?
I want my terrain texturing to be drawn with a set of tiled images, but I want to be able to specify the areas of application of each tile-type with low-res image(s). Think of the map/texture pairing of ProceduralSplatTextureGenerator.addSplatTexture(map, texture). I do not want to base the tile selection on elevation like ProceduralTextureGenerator, but n.p. if I can accomplish what I want with ProceduralSplatTextGenerator and ignore the height-value-mapping features. The real reason why I don't think any kind of ProceduralTextureGenerator will work for me here is that it defeats the reason that I want to tile: I do not want to create a huge intermediate image with no tiling.
It looks like my goal is possible by following the example of TestTerrainSplatting.java, which does not use ProceduralSplatTextureGenerator. I would very much prefer not to, because the required Multi-pass functionality adds an extreme amount of otherwise unnecessary complexity. Besides the point that I don't want to lose a day learning a totally new subject, I wonder how long it will take me to get that working for my StandardGame/Game state setup. Quite disappointing that jME doesn't have a GameState version of SimplePassGame. I guess I will have to study SimplePassGame.java and make sure my Game State renderer does the same thing… would that tactic work?
… Oh, and another thing that worries me about the TestTerrainSplatting technique is that it seems it would use one video card texture slot for each tile image. I have a poor understanding about the texture count limitation. I do not have a low-end or old video card, but it reports only 2 texture slots. Even if there were 6, it just doesn't seem right that with jME I can only render 6 different textures at a time! I've been thinking that the limitation must be per-TextureState, but texture states are just a software abstraction, and just using more Java objects isn't going to get around a hardware limitation about displaying textures simultaneously. Very confused.
i dont know about the splatting stuff.
But for a FengGUI example, i simply created a PassManager inside a Gamestate to reuse existing GameStates and render them in Passes.
And a Wrapper RenderPass for the GameStates.
http://www.jmonkeyengine.com/wiki/doku.php?id=fenggui_jme_appl_using_standardgame&s[]=gamestate
As I understand it:
The number of texture units is the number that you can access simultaneously, such as multitexturing a single mesh or even face. The jME TextureState does reflect the underlying OpenGL and ultimately hardware architecture. So more than one texture in a state is using up texture units, one per texturestate is only using one texture unit no matter how many total in your app.
For splatting, what you describe is pretty much standard texture splatting as I read it. A low res mask and a tiled detail image per layer. I don't know about ProceduralSplatTextureGenerator, but it sounds like a way of faking it.
I think you're going to have to use either passes or shaders to do splatting, or both. But I don't think you'll have too much trouble with it. SimplePassGame doesn't actually do that much when you look at it, you can just put the same calls in your own app.
Thanks to both of you for the education.
From other replies I've read, it looks like you are right on target about ProceduralSplatTextureGenerator. Convenient for height-map integration, but bakes in replicated tiles.
Now, follow-up questions…
Most importantly, based on the examples I see and what you have said, I think I should hit no limitation here, since each render pass will use a different TextureState, right? If so, why did you write, "either passes or shaders to do splatting, or both"? What other limitations and complexities am I going to run into which would necessitate shader customization (shudders with fear)? I'm concerned that the shader tactic would be LWJGL/JOGL-specific, no? Could you refer me to anything to help me determine whether Muti-pass, Shaders, or both are better in terms of simplicity and performance, for my situation?
Is the TextureState-limitation-independence due to the cards rendering only one-TextureState-at-a-time?
I’m not an expert on the low level stuff so this is subject to correction :evil:
The graphics card has a set of states which describe how to render something. The TextureState describes what textures are used. A TextureState can have multiple textures, number limited by the hardware. One mesh has one TextureState, but one TextureState can be applied to many meshes. State changes are an overhead, so sharing them where possible is effecient. But you still need a lot if you have a lot of different textures.
For RenderPass based splatting such as in TestTerrainSplatting, you might have one TextureState per layer (eg. grass, rock, road). Each TextureState will have two Textures (detail, mask). Since a mesh can only have one TextureState, multiple passes are used to create the whole effect. Basically it amounts to draw all the grass bits, now draw all the rock bits, now draw all the road bits. However many layers you have, you only ever use two texture units. But you have a draw call for each layer, and you’re probably filling a lot of transparent fragments.
That’s all fixed function stuff. With a shader it can be done differently as you can tell it explicitly how to combine the textures. You don’t need to use a shader at all to do splatting, but it may be faster. GLSL is a part of OpenGL so a shader should work with any binding. But well, you know, should…
Probably, pass based is simpler while shader based is (perhaps) faster. Momoko_Fan’s supports both with simple switching of modes. I would give that a try.
PS.
If so, why did you write, "either passes or shaders to do splatting, or both"?
That was just a response to your point that mulitpass adds a lot of complexity. It kinda does - but it's either that or a shader.. or both }:-@ If you just rip out bits of SimplePassGame and one of the splatting examples, it isn't too hard to implement.
Alric said:
...
Probably, pass based is simpler while shader based is (perhaps) faster. Momoko_Fan's supports both with simple switching of modes. I would give that a try.
Reg. Momoko_Fan's solution:
Egad. 10 pages of history, and it begins with the assumption that you are familiar with the first try. I hope I don't work through this to find out it's yet another neglected product that I'll have to update myself to get to build and work with jME 2 HEAD. I'm familiar with his copious and amazing work, but I know that Momoko_Fan is fully occupied with non-jME stuff lately.
I've had it work out of the box with both JME1 and 2. But it is added complexity.
For the most straightforward approach, TestTerrainSplatting is quite reasonable - it just uses on multitexturing and passes. You could probably trim it down even further if you wanted. Probably not worth it though.
Alric said:
I've had it work out of the box with both JME1 and 2. But it is added complexity.
For the most straightforward approach, TestTerrainSplatting is quite reasonable - it just uses on multitexturing and passes. You could probably trim it down even further if you wanted. Probably not worth it though.
After studying that Topic, it looks like the Momoko_Fan's system may be a good match for what I want . So, I'm in a holding pattern until I can find out where the code base and wiki are (I've posted a query to the topic). I'll work with the TestTerrainSpatting method until somebody can point me to Momoki_Fan's. (I have some unrelated tasks I need to take care of now anyways).
Alric said:
I've had it work out of the box with both JME1 and 2. But it is added complexity.
For the most straightforward approach, TestTerrainSplatting is quite reasonable - it just uses on multitexturing and passes. You could probably trim it down even further if you wanted. Probably not worth it though.
Yes, it was easy to get PassNodes doing just what I want. Satisfies this need, and I can look into Momoko_Fan's system when I have time to. Seems that my variant of JMEDesktop is more compatible with Multipass than FenGUI, because the standard rendering of my desktop has no problem working at the same time as the game-world Multipass (without all the accommodations that I see made in the FenGUI customization).
I was worried there for a while, because when I applied the same technique to a simple Quad first it wouldn't work. Seems like I need to somehow duplicate the texture coordinates from slot-to-slot in the TextureState like TerrainBlock.setDetailTexture() and TerrainPage.setDetailTexture() do, but I don't think I'll need to do splatting to non-terains for a while yet.