changing alpha when blitting a texture

[raft]

hello,

first my aim: i want to port karga speech bubbles to GL renderer. they are currently blitted over awt.Graphics by using methods of graphics class. the bubbles has a popup effect, that is when they first appear they have an alpha value of 0 and alpha value increases in time giving a feeling of they appear from nothing.

how can i do that with GL renderer ? can i change alpha value of a texture when blitting it ? FrameBuffer.blit(..) method doesnt support it. Texture class itself also doesnt have any methods to change alpha.

Texture has an add method to mix two or more textures with some weight. adding bubble texure to an empty texture with an increasing weight may be an option, but that way colors will also change in time.

what else can i do ?

thanks,
r a f t

[Jonas]

hi

I think you could use the new overlay class to do that.

Or create a billboarded plane, add the texture to it and raise the objects transparency instead of the textures transparency..

Or just use graphics to manipulate the image the texture is made of.

[EgonOlsen]

Manipulating the texture is most likely too slow, because it require a texture upload to the graphics card each time. But as Jonas said, playing around with setTransparency may work. There are some config settings in Config to tweak transparency for a wider transparency range than the default range.

[raft]

thanks for the anwers

well, i dont want to use planes since it will create other problems for overlapping bubbles:

* rendering very close objects with transparency has some sorting problems
* more importantly, bubble text will be blitted after all bubble images has been rendered and it will look very strange. (placing text on planes proved to be a very bad idea)

does LWJGL offer methods to blit with transparency ? maybe jPCT may expose them (this can also be done in sw renderer) ? or else maybe i can use lwjgl methods directly

ps: karga bubbles try to not overlap but they do overlap for some time. for example during the process of going off the way

[EgonOlsen]

I don't understand the problem exactly. Maybe you can illustrate it somehow? The Overlay-class can change the depth of the bubbles if needed (without changing the size), so sorting shouldn`t be an issue. I don't get the section about the text. First, you render the bubbles, then the text on top of that? If so, what's the problem with this approach?

OpenGL doesn't really support bitmap blits in a usable way. You always have to fall back to triangles, which is what jPCT does too. So i don't see how using LWJGL directly can improve the situation. Then again, i don't understand the situation right now...

[raft]

ok, so sorting wont be issue. for text blitting here is an illustration:

this is how it's now. bubbles are rendered one after another depending on some z order


this is how it will look if we first render all bubble images and blit text on them later

[EgonOlsen]

I see...rendering the text into a texture isn't an option? You could use a pool of textures for this to avoid that texture memory fills up after time.

[raft]

wont rendering text to texture kill performance ? other than that, text is very sensitive for scaling. even a very slight scaling makes it look very ugly.

i planned to use feng gui's text renderer for text. it's very handy, can create textures from awt fonts on the fly. the result is very similar to awt.Graphics.drawString(..) method. that's also one of the reasons that i want to use blit someway, it will require a minimal code change.

you said lwjgl doesnt allow directly blitting images but requires usage of triangles. i guess that means FrameBuffer.blit(..) also uses a plane behind scenes. if so, the main difference between overlay and blit is, overlay uses an Object3D which is effected from perspective but blit isnt, right ? if this is the case, isnt it possible to use alpha and scaling in blitting ?

[EgonOlsen]

About rendering the text into a texture: Drawing the text once into the texture shouldn't be that much of an issue. I requires a new upload of course, but as long as you don't do this every frame, it should be ok.

Yes, blit() uses a plane consisting of two triangles behind the scenes. It's very similar to Overlay (Overlay isn't affected by perspective, because it auto-adepts to the camera similar to billboarding) with the excpetion that it doesn't include the overhead of an Object3D.
Alpha in blitting is already possible, but it's currently limited to the alpha channel of the texture, i.e. it's not very dynamic which means that fading will still be an issue.
Adding dynamic transparency to blitting (limited to the OpenGL renderer at first) seems to be quite easy. Adding a kind of scaling should be doable too. I'll look into it.

[raft]

thanks, i will be glad indeed

why is it limited to GL renderer ? it should be trivial in sw renderer too. Graphics2D.setComposite(AlphaComposite.getInstance(...)) provided you hold texture in image format. i dont know about java 1.1 compatibility..

i was looking into feng gui docs, it does allow drawing scaled images but with no alpha adjustment. if you add scaled/alpha blitting i will be more than happy and use it, otherwise i will try to modify feng gui blitting to support alpha. i certainly prefer jPCT in this case, as bubbles arent part of gui and i dont want to depend another library at that level

btw, i may post or mail relevant part of feng gui source

[EgonOlsen]

jPCT does everything on the int/byte-level when using the software renderer. I don't use any image-related stuff except for loading data. After that, it's all bit-fiddling...

[raft]

i see 

[EgonOlsen]

I have the modified blitting stuff working, i think.

Unfortunately, i only have an older version of jPCT's sources at hand at the moment, so can't update the 1.16rc right now with it. I'll try to add it on monday to the correct branch.

[raft]

great, thank you

[EgonOlsen]

I've added the requested stuff...it's not fully tested, so you may still encounter bugs in it. Get it here: http://www.jpct.net/download/beta/jpctapi116rc3.zip (this time without CRC-errors...hopefully...).
The new blitting works in hardware as well as in software mode. In software mode, it wraps the blitting-call in an Overlay...quite tricky but it seems to work fine...