OpenArena Message Boards

OpenArena Contributions => Development => Topic started by: dmn_clown on November 17, 2007, 03:22:31 am



Title: Framebuffer bloom test
Post by: dmn_clown on November 17, 2007, 03:22:31 am
I compiled test binaries to see how it plays on other hardware.

experimental/fbo-test/ in the svn.


Title: Re: Framebuffer bloom test
Post by: Ylle on November 17, 2007, 08:06:48 am
Using the precompiled windows binary:
Nothing on my integrated Intel Express. Not that suprising, but eh, going to try it on a more sensible card in a few moments.

Edit: C:\Documents and Settings\%USERNAME%\Application Data\OpenArena\baseoa\ files untouched.


Title: Re: Framebuffer bloom test
Post by: fromhell on November 17, 2007, 08:07:27 am
Also for some reason my q3config in personaloafolder/gamedir disappeared


Title: Re: Framebuffer bloom test
Post by: Ylle on November 17, 2007, 08:20:34 am
I tried
/r_bloom 1
/r_framebuffer_bloom 1

Edit: nothing on a ati radeon 9250 either.


Title: Re: Framebuffer bloom test
Post by: randombloke on November 17, 2007, 09:58:54 am
Well that was interesting.  Using:

ioquake3.x86.exe

seta r_framebuffer 1
seta r_framebuffer_bloom 1

This generates a red screen with an inverse open arena logo on it.  Printed on top is the english alphabet, as it would appear in a mirror on a horizontal line.

Using:

ioquake3.x86.exe

seta r_framebuffer 1
seta r_framebuffer_bloom 1
seta r_framebuffer_rotoscope 1

Very similar, only a black background this time.  An extended character set can be observed as well, again, it too is a mirror reflection.

As this has no effect on my .exe.

//Correction: I don't use SDL as its not required when using windows.  I just added it to allow the experimental .exe to execute.  So, I assume I don't have the hooks for these values in my .exe.


Title: Re: Framebuffer bloom test
Post by: kit89 on November 17, 2007, 11:03:00 am
Worked fine for me. Tho it crippled the framerate.

r_bloom 0
r_framebuffer 1
r_framebuffer_bloom 1

(http://img264.imageshack.us/img264/3476/shot0000cf8.th.jpg) (http://img264.imageshack.us/my.php?image=shot0000cf8.jpg)

and

r_bloom 0
r_framebuffer 1
r_framebuffer_bloom 1
r_framebuffer_rotoscope 1

(http://img264.imageshack.us/img264/3421/shot0001hi0.th.jpg) (http://img264.imageshack.us/my.php?image=shot0001hi0.jpg)

That was using a Nvidia Geforce 6 6600 256MB


Title: Re: Framebuffer bloom test
Post by: fromhell on November 17, 2007, 11:09:14 am
oh btw the rotoscoping works, and i get high framerates with that on. The bloom never works

in rotoscope the model shading appears flat shaded than gourad :( very faceted. (http://openarena.ws/shots/fun/roto5.jpg)


Title: Re: Framebuffer bloom test
Post by: Crash!!! on November 17, 2007, 04:35:24 pm
ok the bloom when turned on is not visible and it cripples framerate


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 17, 2007, 10:06:56 pm
Framerates would drop, its all done on the GPU instead of the CPU.

Have you tried playing around with the defaults?  The effect is subtle, like bloom lighting should be.

 
Code:
    r_framebuffer_bloom_brightness = "0.85"
    r_framebuffer_bloom_sharpness = "0.75"
    r_framebuffer_blur_ammount = "7"
    r_framebuffer_blur_size = "128"



Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 18, 2007, 04:15:39 am
ati x1600 linux 8.37 -> nothing works
windows coming soon!


Title: Re: Framebuffer bloom test
Post by: next_ghost on November 18, 2007, 04:33:36 am
Gentoo Linux, ATi Mobility Radeon x1600, proprietary drivers v8.41, framebuffer+bloom works, framebuffer withou bloom did work, then stopped working, rotoscope looks like fromhell's screenshots.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 18, 2007, 04:50:12 am
ati x1600 linux 8.37 -> nothing works
windows coming soon!

edit:
my bad fbo bloom and rotoscope works (you can combine two rotobloom bloomscope) on linux even with standard ubuntu gutsy restricted ATi driver (version 8.37)

windows fails badly I couldnt even enable fbo -> some error message with an emo face -> :(

further edit:
I applied the patch myself and built one on linux
but it wont work... plus my binary size is bigger ... how did you build your linux x86 binary?


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 18, 2007, 05:55:24 am
   //create the framebuffer texture space
   if (glConfig.stencilBits > 0) {
      R_FrameBufferCreate_ZS(&screenFbuffer, glConfig.vidWidth, glConfig.vidHeight);
   } else {
      R_FrameBufferCreate_Z(&screenFbuffer, glConfig.vidWidth, glConfig.vidHeight);
   }

R_FrameBufferCreate_ZS is the problem here
so if you set r_stencilbits to 0 you have more chance to run fbo

edit:
after setting r_stencilbits to 0 it my build worked too


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 18, 2007, 06:22:39 am
further edit:
I applied the patch myself and built one on linux
but it wont work... plus my binary size is bigger ... how did you build your linux x86 binary?

Code:
  OPTIMIZE = -O2 -march=i586 -fomit-frame-pointer \
      -falign-loops=2 -falign-jumps=2 \
      -falign-functions=2 -fstrength-reduce
    HAVE_VM_COMPILED=true

no ffast-math no funroll-loops (great website, bad compile flag).

btw - setting r_framebuffer_blur_size to 10 makes the effect far less subtle for the people that aren't sure if something is happening.


Title: Re: Framebuffer bloom test
Post by: randombloke on November 18, 2007, 08:41:11 am
So, why did I get the mirror image test card thingy?

//I know...my technical descriptions are very complex... :)


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 18, 2007, 09:06:05 am
Quote
I don't use SDL as its not required when using windows.


...waits for the obvious to sink in...


Title: Re: Framebuffer bloom test
Post by: gord on November 18, 2007, 03:22:13 pm
Hello, I am the developer of this patch, there are a few things to note:
this patch requires a few extensions. i didn't apply more rigorous extension checking before but i'll add that tonight, for now make sure you defiantly have the following (windows users can use a program called glcaps or something like that, i forget. Linux has glxinfo of course).

GL_EXT_packed_depth_stencil (or GL_NV_packed_depth_stencil)
GL_ARB_depth_texture
GL_EXT_framebuffer_object

GL_ARB_vertex_program
GL_ARB_vertex_shader
GL_ARB_fragment_program
GL_ARB_fragment_shader
GL_ARB_shading_language_100
GL_ARB_texture_non_power_of_two

people having problems when stencil buffers are enabled i would guess do not have packed depth stencil support, this chart suggests that some ati cards for whatever reason do not have this at all: http://www.labri.fr/perso/granier/OpenGL/ext/videocards.html if someone with an ati card could clarify this for me that would be great, if it turns out that ATI really don't have any form of depth-stencil framebuffer support i will just auto-disable stencil so that it at least works.

for people who seem to be having problems with the lighting looking flat shaded, i would first make sure that its not a problem that already exists that is just 'highlighted' by the colour modification the rotoscope shader does, just turn off the bloom/rotoscope effects and take a very close look at the model in question (also if you could post a screenshot with that setup that would be great, so i can take a close look for myself)

for the person apparently having problems with sdl make sure that you are using the latest svn version, with that version there is only sdl support iirc.

i would also like to clarify some of the cvar names (i really need to make these more obvious)
"r_framebuffer" - toggles the framebuffer rendering path
"r_framebuffer_bloom" - toggles the bloom code
"r_framebuffer_blur_size" - the size (in pixels) of the blurred image, higher values will be a higher quality with less popping but obviously, slower (you may need to increase the blur amount too)
"r_framebuffer_blur_ammount" - the size in percentage of the blur, the 'best' value for this is 100/blur_samples.
"r_framebuffer_blur_samples" - only three values will work for this 5, 7 and 9. higher values = higher quality.

"r_framebuffer_bloom_sharpness" - the sharpness between the bright colours and the dark ones when blooming
"r_framebuffer_bloom_brightness" - pretty obvious, 0.85 is a sensible value. for testing i use 10.0 (to make it really show)

"r_framebuffer_rotoscope" - enables rotoscoping
"r_framebuffer_rotoscope_zedge" - uses a different method for edge detection which requires the zbuffer be bound to a texture.

finally how the effect 'should' look, this is my box with regular quake 3 demo four. http://s239.photobucket.com/albums/ff277/gordallott/


Title: Re: Framebuffer bloom test
Post by: gord on November 18, 2007, 05:35:33 pm
latest patch should fix problems for some ati users
http://bugzilla.icculus.org/show_bug.cgi?id=3422


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 19, 2007, 12:01:49 am
updated the bins


Title: Re: Framebuffer bloom test
Post by: fromhell on November 19, 2007, 04:38:07 am
Still not seeing bloom, and still not keeping cfg.


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 19, 2007, 06:02:19 am
does /writeconfig work?


Title: Re: Framebuffer bloom test
Post by: gord on November 19, 2007, 08:33:45 am
the patch should not have anything todo with writing config files, a few cvars are added but not in any way that touches that code. i would suspect problems elsewhere. regarding it not working with that ati card could you please post some sort of information, ie: make sure its run in a terminal of some sort and see if there are any warning messages or anything (especially regarding shader info logs, it could be that your chip does not support the exp() glsl function). also make sure you really turn the bloom brightness up to make sure you arn't getting it.


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 19, 2007, 03:38:10 pm
It doesn't behave nicely when the gl extensions aren't supported (radeon mobility r300e with xorg's ati driver) they are ignored when set before entering a map, but in game changes followed by vid_restarts crash the game.


Title: Re: Framebuffer bloom test
Post by: gord on November 20, 2007, 02:49:38 pm
I should have a patch that might fix that up tommorow night (hopefully). i was getting a similar experiance but one that managed to crash xorg entirely.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 20, 2007, 03:46:28 pm
I should have a patch that might fix that up tommorow night (hopefully). i was getting a similar experiance but one that managed to crash xorg entirely.
I love you
will you add vbo?


Title: Re: Framebuffer bloom test
Post by: gord on November 22, 2007, 09:11:19 am
http://bugzilla.icculus.org/show_bug.cgi?id=3422
latest patch just uploaded. lots of fixes and refactored a lot of the code. should be more compatible on more systems and should be marganally quicker for some people.

will you add vbo?

are vbo's needed? the quake 3 code is pretty quick regarding this already.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 22, 2007, 02:02:22 pm
I disagree


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 22, 2007, 09:47:17 pm
I'll update the bins tomorrow.


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 23, 2007, 02:13:24 pm
updated the bins, if you are having issues with the config not saving please move or rename your userdata directory and start from scratch for an accurate assesment.

Also make sure this is from a clean openarena install (i.e. no thirdparty mods, xfire, etc.).


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 25, 2007, 01:01:37 pm
are vbo's needed? the quake 3 code is pretty quick regarding this already.

I think non-framerate dependent soft particles would be nice.


Title: Re: Framebuffer bloom test
Post by: gord on November 25, 2007, 04:33:43 pm
agreed, but thats the kind of things that needs GLSL integration into the main codebase. very 'doable' but hard to maintain against mainline ioquake3. which would require a fork and losing all the advantages of ioquake3.
there are lots of things that i keep thinking would be nice to impliment into the quake3 engine (such as reflective/refractive water, per-pixel phong shading instead of gourrard shading on the models, normal mapping, depth of field rendering, motion blur, colour correction... etc) but it would all be too much of a pain to keep patches compatible with ioquake 3 and they don't seem interested in any inclusions in the main codebase that 'improve' the graphics in any way.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 25, 2007, 05:27:54 pm
see xreal


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 25, 2007, 06:44:09 pm
which would require a fork and losing all the advantages of ioquake3.

That's the bitch of it, and there are too few people working on OA to support anything but minor changes to the engine.

see xreal

An "xreal-like" particle system might be doable but requires adding some sort of scripting support to the engine (they use lua but other scripting languages are feasible).


Title: Re: Framebuffer bloom test
Post by: fromhell on November 25, 2007, 08:40:29 pm
requires adding some sort of scripting support to the engine (they use lua but other scripting languages are feasible).

How did all those q3 mods do it in cgame then :S


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 26, 2007, 01:28:35 am
How did all those q3 mods do it in cgame then :S

Those are not soft particles.  With soft particles the particle will get softer and softer as it comes closer to map geometry until it becomes transparent.  It eliminates the hard edges you'll see in rocket trails, etc. when fired close to a map floor.

XreaL particles aren't soft, from what I can see.

nVidia's white paper (http://developer.download.nvidia.com/whitepapers/2007/SDK10/SoftParticles_hi.pdf)(pdf) on soft particle's.


Title: Re: Framebuffer bloom test
Post by: gord on November 26, 2007, 07:19:25 am
i think fromhell was talking about the general idea of a (better?) particle engine in q3. which could be very easly put into qvm's without any need for scripting.  tremulous's 'particle engine' for example.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 26, 2007, 08:48:27 am
lua is a choice of xreal
of course you can do the same using cgame code and a text file

btw I said "see xreal" for renderer changes not for particles

there are only a few people working on quake3
(I don't count those guys who are doing some minor changes, bugfixes, trying to make it work on other platforms
 after all I dont care about playing quake3 arena on  <place your favorite OS> after 7 years if there is nothing new visually ) It is not as popular as q2 and q1


Title: Re: Framebuffer bloom test
Post by: w1zrd on November 26, 2007, 10:07:12 am
lua is a choice of xreal
of course you can do the same using cgame code and a text file

btw I said "see xreal" for renderer changes not for particles

there are only a few people working on quake3
(I don't count those guys who are doing some minor changes, bugfixes, trying to make it work on other platforms
 after all I dont care about playing quake3 arena on  <place your favorite OS> after 7 years if there is nothing new visually ) It is not as popular as q2 and q1
Sliding off-topic, but Q3 has a arger, and more mature, community than Q2 has. It's also thanks to Q3 community that OA keeps growing.
Q1 players go with EZ/f/nQuake and Q2 players have moved on to Q3, or they stopped playing in general.
What Q3 has, that others don't, is responsive controls and incredible gameplay, that's why it's still alive, not because some 'unreal-mega-babe-busty-42DDD' model is dancing about as a 250k polymesh with megatextured hair and soft particles from her armpits.
Xreal won't go anywhere unless tr3b lands on planet earth.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 26, 2007, 10:16:18 am
popularity -> popularity among coders
and it looks like they hate q3 code


Title: Re: Framebuffer bloom test
Post by: w1zrd on November 26, 2007, 11:23:57 am
popularity -> popularity among coders
and it looks like they hate q3 code
I was under the impression that q3 source was relatively easy and structured to work with though.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 26, 2007, 02:01:02 pm
in a pink world with pink bunnies maybe
(or if you live inside the game code)


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 26, 2007, 02:07:58 pm
lua is a choice of xreal
of course you can do the same using cgame code and a text file

btw I said "see xreal" for renderer changes not for particles

there are only a few people working on quake3
(I don't count those guys who are doing some minor changes, bugfixes, trying to make it work on other platforms
 after all I dont care about playing quake3 arena on  <place your favorite OS> after 7 years if there is nothing new visually ) It is not as popular as q2 and q1

An external script-based soft-particle system would be easier to maintain against the existing code base.


Title: Re: Framebuffer bloom test
Post by: iLeft.bye on November 26, 2007, 02:33:59 pm
you can add most of the lua via cgame exports/imports and actual lib links to the client
(I tried it with game/server and it worked So I believe cgame/client would also work)


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 26, 2007, 05:54:25 pm
Yes, they'd both work but it really comes down to ease of maintenance against a code base that changes frequently.


Title: Re: Framebuffer bloom test
Post by: TheDoctor on November 26, 2007, 07:25:15 pm
bloom works on my radeon x2900xt hd and my ati x1250 integrated


Title: Re: Framebuffer bloom test
Post by: gord on November 27, 2007, 07:56:14 am
hurrah thank you TheDoctor.

"An external script-based soft-particle system would be easier to maintain against the existing code base" the point about a scripting system not being needed for a particle engine is that if you implement it in a qvm you could essentially just have your own open arena qvms that you develop privately as a 'mod' and leave ioquake3 alone altogether. 'soft' billboard effects however are something that requires a lot more messing about in the main code.

I would also like to state that i have worked on the quake2 source before and i can honestly say the quake3 code is much cleaner and well thought out. its a little scarier when you first take a look see but on the whole its much nicer. i think the real reason that people havn't took to coding it so much is because its a multiplayer based game, which means if you made substantial changes to the codebase you couldn't have your client in the same games as people using the mainline client.

well that's whats keeping me off doing anything substantial anyway. if i were developing a separate game i would use the q3a codebase over say Ogre or Crystal space any day. would be a lot of fun getting the q3a code into shape -_-


Title: Re: Framebuffer bloom test
Post by: dmn_clown on November 27, 2007, 01:32:02 pm
setting r_framebuffer_bloom back to 0 and issuing a /vid_restart drops the game to a tiny 200x300 corner of the screen.


Title: Re: Framebuffer bloom test
Post by: gord on November 28, 2007, 07:47:53 pm
oop, forgot to reset the blur value on start (only its default compiled value of 0), fixed and updated to latest svn: http://bugzilla.icculus.org/show_bug.cgi?id=3422


Title: Re: Framebuffer bloom test
Post by: Dennis1990 on October 26, 2009, 01:46:56 pm
Hello Open Arena Users

Ive want to test it out,ive downloaded the binaries on experimental of the openarena/svn server.
But when ive start it Ive get a Red Screen (I have a ATI MOBILITY RADEN HD 4570)
does anyone know a solution for this?

Ans can someone make this patch compatible with some later ioq3/openarena revisions?


Thanks a lot for your help


Title: Re: Framebuffer bloom test
Post by: Cacatoes on October 27, 2009, 07:46:00 am
Sorry but why don't you download the game like anyone else ?

http://openarena.ws/files.html


Title: Re: Framebuffer bloom test
Post by: sago007 on October 27, 2009, 09:17:23 am
Ans can someone make this patch compatible with some later ioq3/openarena revisions?
The patch on the svn (oachanges.diff) is extremely old (2007). I got later patches and in the experimental thread I have often included .svn-files so you can extract a patch from it.

I created a patch just a few days ago to work with the newest ioquake3 but since then even more changes has been applied to ioquake3 svn and I have therefore withhold the patch until I could check it with the even newer versions. I would like to have SDL 1.2.14 support in the next version, so Windows users can use DirectInput and bind caps-lock.


Title: Re: Framebuffer bloom test
Post by: Falkland on October 27, 2009, 10:26:59 am
I would like to have SDL 1.2.14 support in the next version, so Windows users can use DirectInput and bind caps-lock.

ioquake3 r1707 : * Update SDL headers and win32 libs to 1.2.14

http://icculus.org/pipermail/quake3-commits/2009-October/001624.html


Title: Re: Framebuffer bloom test
Post by: Dennis1990 on October 27, 2009, 10:53:34 am
@sago i mean the framebuffer patch.


Title: Re: Framebuffer bloom test
Post by: Dennis1990 on October 27, 2009, 02:01:24 pm
so can someone compile openarena or ioquake3 with the latest patch here http://bugzilla.icculus.org/show_bug.cgi?id=3422
i cant get it to compile a lot error essags on msys and vc++