Using RenderToTexture for object imposters?

#1 The legacy terrain code shows how to properly render to a texture. That looks very similar to some problems I ran into when developing it. :)

#2 Ah, thanks for pointing me to that(and for the quick reply). :)

So now I have it rendering to a texture.

Particles

Imposter

Looking at those 2 shots, you can easily tell that it's not working how anyone would want.
There's 3 problems that I can notice:
-Particles are not rendered on screen at the normal size.
-The rendered-To texture does not display correctly(sometimes is inverted on the x, sometime on the y, sometime it renders what looks to be correctly).
-The color depth is completely lost.

I think if I used a full screen texture to render to, it would solve problem #1. However this texture is stored as a pointer in my object and I'm thinking that will cause problems/slowdowns. Fiddling with the texture co-ords will probably get me somewhere with #2, but I have no idea about the third issue.

Edit: To clearify what I'm trying todo: I want to render my particles to a small texture either 256x256 or 512x512(perhaps even 128) and use that as a billboard. These would be gernerated as needed like when the camera moves far enought to warrent it, or the particle positions change greatly(then I'd probably want to have to rendered textures and fade one out to the other).

#3 I still do not really understand why you are rendering imposters to ANOTHER imposter... I would help you then, but I really do not understand what/why you are doing... I don't see this method you are proposing as being greatly superior to simple low-density volumetric clouds.

#4 Take for instance a player standing around in a city or just out on the open terrain looking at the particle effects. Would it be more efficient to:
render one imposter that's maybe only generated once and only do billboarding for that
OR
render hundreds of particles and calculate billboarding for each one of them every frame?

#5 What would look more realistic is also a key question you are missing here.

Also, you are not taking into account how much speed loss occurs with either method... I believe the difference is negligible if we are talking about modest numbers of clouds.

What exactly is considered a great enough change in relative change in order to warrant a new billboard being generated from your particle base?

You also stated that your clouds will be moving... a cloud that only regenerates once in a while is going to look... well... crappy compared to a true volumetric cloud.

#6 Currently, rending the imposter VS all the particles makes a HUGE difference. The particles drop me about 80 FPS, while I can't see any FPS drop using the single imposter.

Is there anyone else that could perhaps help me out with this?

#7 I am not in any way committing anyone to this or anything (can't do that even if I wanted to!), but if/when they get a chance to look at this thread, Brian (Ramage) or Ben might have some supplemental input/guidance for this idea. Please realize however that both of them are buried neck deep in other areas, so it may take some time!

#8 I guess I'll go ahead and put this project on hold for a while. I find that if I come back to a piece of code after taking a break from it, I'll beable to look at it in a new light.

#9 My opinion is that you are, according to our conversation on IRC, going for a very, very high-end market.

Kuiper uses full volumetric clouds, and it is being designed for low-end (like my PC) systems...
You don't need to skim a few FPS using imposter clouds at the expense of quality that particle clouds have... your market's systems can handle the burden.

#10 Imposters should not drop quality that much, if done right. Actually, well-done imposters are seamless, moreso when you use them for things that are usually very far away and move slowly, like clouds. Not to mention you can render a hell lot more clouds that way.

#11 How often do you plan on updating the imposter?

Let's say you had a decent Theora (et al) movie of some effect (volcano, clouds, etc),
then using a small number of 'movies' per imposter but using 2+ imposters in a particle
fashion may provide realistic, natural effects using smaller number of frames, and particles.

The texture bandwidth would compete, but if the overall effect was greater, then the
effect/bit would be higher and worth it (if that's what your optimizing for).

Downsides?

#12 Huh... isn't that the 'ol "animated pre-rendered sprite", that was used a lot in the early 32-bit days? The concept of imposter is that it is rendered dynamically, but only once in a while.

Trees, for example. You can have a large and detailed tree model. Once it gets far enough, you render it to a texture, from from the same angle you're seeing it. Then you only update the texture when the difference between the view angle and the recorded angle becomes greater than a certain tolerance value.

For clouds, it's possible to abuse the impostors even more if you use them in a game where it's impossible to fly through the clouds. It's possible to render absceneamount of slowly animated clouds, by updating only a few imposters per frame. The imposters themselves can move along the wind direction, and update only based on distance to camera and view angle.
And if you blend between the old imposter texture and the updated one, you'll avoid hash popups.

#13 Has anybody looked at this: www.markmark.net/SkyWorks/ not that it helps Josh much but it is an interesting approach.

#14 Impostering clouds is a time-honored tradition - certainly, developing the core tech and posting it as a resource or something is hardly a bad idea. :)

The trick is getting it to all work out right so it looks good. There's nothing but hard work and trial and error between here and there.

#15 I was aware of sprite animation (having long ago attempted such on a TI994a using character PEEK/POKE, not fun),
but do any current techniques take advantage of the information contained in the compression?

There is a correlation between the human perception and how the information was compressed, and this information
perhaps could be leveraged (e.g. MP3). While rendering to texture can produce 'some' effect, I doubt any real-time
rendering will compete with off-line compression and the advanced image analysis that could be applied.

Trompe-l'oeil is all that's needed.

#16 Using SkyWorks is on my things to do list but it's not the current item I'm working on. However after reviewing the code again it wouldn't be that difficult to incorporate it into TSE-- just time consuming. Mr. Harris does provide the code completely free, we just got to retain the copyright notice -- humm.... :)

#17 Lary: Actualy, the markmark.net stuff on rendering real-time volumetric clouds was what motivated me to take a shot at this. I downloaded SkyWorks source, however I couldn't get it to compile so I haven't looked at the code.

#18 It will compile with VC 6 but not VC 7.