I have looked through the previous threads regarding "texture splatting" and decals, but the solutions proposed seem to be a little complex for my needs. Mainly because they seem to be geared at splatting on a mesh, and under the thought that the decal might overlap a vertex.
My needs are a bit more controlled. I am looking for the easiest way to use decals on a flat code-generated plain. That is the only surface I need to 'paint' to.
The solution I am considering now are to use a flat 2poly rectangle laid on top of the plain. The problem is this solution seems very hackish and ugly to me. Another concern is I need to display very large quantities of decals at a time (200+ estimate), so I am concerned about the load monster encountered when having to many independent objects. I suppose I could try monsters technique for combining the decals into a single object, but this is already going a little more in depth then I really want.
Is there any better, simple way to perform this?
As always, Thanks in advance.
Yet Another Decal Thread - Sorry :)
-
- Halfling
- Posts: 88
- Joined: Wed Sep 29, 2004 3:33 am
- Location: Ohio, USA
Yet Another Decal Thread - Sorry :)
I <3 the OGRE Wiki, and SO SHOULD YOU! 

-
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
-
- Halfling
- Posts: 88
- Joined: Wed Sep 29, 2004 3:33 am
- Location: Ohio, USA
You say this is not good for temporary decals, however what if a 'clean' version of the texture (since it is a tiled plain) was kept. Perhaps a decal class would keep a pointer to the decal texture, and cordinates of each decal. Then when time ran out (decal should dissapear) it could write the 'clean' texture, and reapply the cordinates that should still be stored.tuan kuranes wrote:Use Sub-blittexture : upload a "decal" texture in the "main" texture modifying it in VRAM. If decals are temporary, it's not a solution.
It's fast enough, particularly if you intend to have many, many decals at the end.
On the contrary, modifiying the whole texture, then uploading it, is slow.
Or perhaps this is far too much overhead, and it would be more effective to keep the decals on permanently (for the level).. I am worried about the ground becoming too crowded with decals, but it would look very interesting I suppose.

Could anyone give me a clue on the source to pull this off? What I (think) I understand so far is that I am going to need a texture with multiple TextureUnitState's, each TextureUnitState beyond the first would be a decal. The thing I am unclear of is how to shove more TextureUnitStates into a Texture, and how to set their cordinates within the parent texture.
I <3 the OGRE Wiki, and SO SHOULD YOU! 

-
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
-
- Greenskin
- Posts: 128
- Joined: Mon Jun 21, 2004 2:34 am
- Location: Victoria, Australia
-
- Greenskin
- Posts: 145
- Joined: Wed Apr 28, 2004 12:10 pm
- Location: Hungary
-
- Halfling
- Posts: 88
- Joined: Wed Sep 29, 2004 3:33 am
- Location: Ohio, USA
Well I took a detailed look into the paginglandscape thread and I am afraid that it doesn't look like it will work for me. The biggest omission (on the TODO list, I believe) was the lack of Octree, which will be important for this project I believe.
If you can try to visualize, the camera will be locked so that on the right side of the screen is a circular 'base' mesh. Coming from the left is army of sprites. The player can move camera "forward" and "backward", which just moves it along a predefined circular path around the circular 'base'. So, due to the inherent camera restrictions, I am thinking that an octree is going to be very effective in this setup to allow me to push more sprites before performance starts to decrease.
If anyone has any new suggestions on how to do this with the Octree Scenemanager or the core Terrain Scenemanager (which is derived from Octree if I am not mistaken), then please reply
Otherwise I am probably going to end digging in the paging landscape manager and see if I can come to understand how it achieves splatting.
If you can try to visualize, the camera will be locked so that on the right side of the screen is a circular 'base' mesh. Coming from the left is army of sprites. The player can move camera "forward" and "backward", which just moves it along a predefined circular path around the circular 'base'. So, due to the inherent camera restrictions, I am thinking that an octree is going to be very effective in this setup to allow me to push more sprites before performance starts to decrease.
If anyone has any new suggestions on how to do this with the Octree Scenemanager or the core Terrain Scenemanager (which is derived from Octree if I am not mistaken), then please reply

Otherwise I am probably going to end digging in the paging landscape manager and see if I can come to understand how it achieves splatting.
I <3 the OGRE Wiki, and SO SHOULD YOU! 

-
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
Adding octree is not very hard, it just wasn't the first on the my TODO list... (not very exciting, I guess... but it's next on my TODO after my end of the week release (displacment mapping))
Anyway, to help you dig into it :
- splatting is mainly done in PLSM2 material files...(splatting*.material) or using shaders (splat.cg)
- And sublittexturing upon deformation is in done in PLSM2 "Instantbasetexture.cpp"
Anyway, to help you dig into it :
- splatting is mainly done in PLSM2 material files...(splatting*.material) or using shaders (splat.cg)
- And sublittexturing upon deformation is in done in PLSM2 "Instantbasetexture.cpp"