www.jpct.net
jPCT - a 3d engine for Java => Support => Topic started by: ToddMcF2002 on May 07, 2007, 03:14:08 pm
-
I need to create a bunch of glowing objects and maybe fake a sun. I've played with the lighting model and just can't seem to get the right effect. I heard a rumor this might be coming up in the next release? Any details? Thanks!
-
Bloom is already available in jPCT. Here's a demo which shows this feature:
http://www.jpct.net/demos/blue/blue.jnlp (http://www.jpct.net/demos/blue/blue.jnlp)
press "b" to toggle bloom on/off
-
Yeah Bloom is already done but the ilumination of jpct still cant project shadows. Maybe you should try a very intense light on a far place to simulate a sun but wont get a really good efect. Its better to put many small lights on certain places to have the ilumination efects.
-
I'm a goof for not noticing BloomGLProcessor.
Its not quite clear from the javadoc where the calls go though.
do I call init() once and process() at the point where I call buffer.displayGLOnly()?
Does anyone have the source for the JNLP test?
-
This demo shows the effect a little better (press 'b' for bloom): http://www.jpct.net/demos/proj/proj.jnlp (http://www.jpct.net/demos/proj/proj.jnlp)
Bloom requires a hardware/driver that supports arbitrary texture sizes. While this is usually true for almost all current hardware, some older drivers (at least for Intel onboard chips) lack support for it.
-
do I call init() once and process() at the point where I call buffer.displayGLOnly()?
It's an implementation of IPostProcessor that can be added to the FrameBuffer and applied by calling FrameBuffer.runPostProcessors(); after the image has been rendered but before the final display-call.
-
So I do the init() once and then right before buffer.displayGLOnly() I call FrameBuffer.runPostProcessors()?
I never call process()?
Post the code to shut me up ;)
-
No need to call init...just add it and run it... like so:
BloomGLProcessor bloom=new BloomGLProcessor();
fb.addPostProcessor(bloom);
....
while (...) {
fb.clear(Color.BLACK);
world.renderScene(fb);
world.draw(fb);
fb.runPostProcessors();
fb.update();
fb.displayGLOnly();
}
-
Thank you sir!
-
BTW: There's a bug in the post processor part of 1.13. The version that i've uploaded in the "getOutputBuffer()-Bug"-Thread fixes it. Just in case you encounter a problem.
-
My framerate went from ~400 to 70 using this effect :o
It is an interesting effect though. I was going to play around with the constructor, but what are the value ranges? The javadoc is pretty vague on the first 3 arguments:
public BloomGLProcessor(int darkening,
int blur,
int strength,
int quality)
-
The drop was to be expected. The effect eats fillrate for breakfast. The higher the values, the more. Usually, the values stand for the number of iterations that are applied in each stage. You *may* apply 2000 blur steps if you like, but...well...it will be sloooowwww. It's similar to the Water-effect: Play around with the values to find a good compromise between performance and quality. There's no exact rule to follow when choosing the values, which may be why the description is vague.
-
Egon, i think there could be a method to make it faster and even make true HDR.
HDR need to have textures converted to float(24bit RGB converted to 3x32bit). It need bigger color values for example for sun. This is usefull in gaussian blur filtering. The main problem is using differend (float textures and float FrameBuffer) rendering procedures when HDR is used.
But there is also good site.
When You separate textures RGB to float R float G float B, You are able to make 3x gaussian blur very fast (you don't need to separate colors while making blur).
Last step is joining float textures to RGB 24 bit again.
I think software blur could be replaced by OpenGL bilineral mapping. Buffer could be shinken and later zoomed to normal size. This cheap method has worst quality than normal blur, but it could be much faster.
But i'm not sure if it works, i never made HDR. This is only not checked theory.
Regards
-
When You separate textures RGB to float R float G float B, You are able to make 3x gaussian blur very fast (you don't need to separate colors while making blur).
...
I think software blur could be replaced by OpenGL bilineral mapping. Buffer could be shinken and later zoomed to normal size. This cheap method has worst quality than normal blur, but it could be much faster.
I'm not separating colors and the blur doesn't work on textures but on the framebuffer. There's also no software blur involved. Everything happens on the graphics card already using bilinear filtering and blending. The only possible speedup (albeit i'm not sure how big it would be...) would break support for older graphics cards, so i'm currently not doing that.