XEffects - Reloaded - New Release (V 1.4)
I've heard of a technique that was used in Heavenly Sword that translates the colours into XYZ, I think it's similar to HSV but allows higher brightness. That guy "Wolf" mentions it on his blog. Might wanna look into that. (Who knows, maybe I will )
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
from what I've read LogLuv is the way forward in terms of easy HDR storage with limited render buffer support.
You can fund encode/Decode code int the comments of this blog post:
http://realtimecollisiondetection.net/blog/?p=15
You can fund encode/Decode code int the comments of this blog post:
http://realtimecollisiondetection.net/blog/?p=15
pushpork
ok... now i sound noobish...
this is what i understand... HDR is blooming the brightpass... and using the LDR to fade into the new luminance, to get the whole gamma adjustment effect... is this correct? if so, you wouldn't really need floating point... or is the tone mapping the essential point that needs the extra precision
oh, and is there any way of directly uploading the screenshots here? or should i just post them to my picasso gallery, then link it?
this is what i understand... HDR is blooming the brightpass... and using the LDR to fade into the new luminance, to get the whole gamma adjustment effect... is this correct? if so, you wouldn't really need floating point... or is the tone mapping the essential point that needs the extra precision
oh, and is there any way of directly uploading the screenshots here? or should i just post them to my picasso gallery, then link it?
Nice to hear that the framebuffers are recreated on lost devices - that's part of the issue addressed, at least. But the app will almost certainly still die if resources created by the user are lost. It probably needs a callback so the user can be notified and can then recreate resources (such as shaders).hybrid wrote:Floatingpoint buffers are not yet supported. The lost device issue has been adressed in SVN/trunk and should have a solution in Irrlicht 1.5. Shaders are not affected by this, though, but it might be the case that the framebuffer is lost and hence the shaders cannot be set...
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
One should be able to recognize this once the beginScene failed and the checkDeviceReset can also hint about a recently reset device. So there are already ways to become aware of distinct states of the driver/device, but I'm not sure if this already suffices. Moreover, all the user created things should, on the long run, migrate into Irrlicht, such that the engine can take care. Right now we need some other ways, though, because we don't support all the features, yet.
No, not quite. Bloom is an effect that works on LDR and HDR, but used correctly it can make HDR images look nice. HDR mean that you store a wider range of colors (i.e. instead of 0.0f->1.0f you have something like 0.0f->5.0f) The bloom then just takes colors above a certain value (so the bright pass) such as 1.0.Anton1 wrote:ok... now i sound noobish...
this is what i understand... HDR is blooming the brightpass... and using the LDR to fade into the new luminance, to get the whole gamma adjustment effect... is this correct?
Current hardware can only display colors in the range 0-1 (an LCD cannot make light a bright as the sun), so the data needs to be scaled, but in a nice way, such as an exponential curve. This is tone mapping.
pushpork
wow, that's deep! nice explanation... thanks to all y'all, i'm working my way forward through this..
hmm.. i think the easiest to do now is get that nadro's patch.. any clue why irrlicht hasn't added support for floating-point buffers yet... i saw that the format is easily available for DirectX render targets
from what i read on the that logluv type blog thingy, it seems integer point buffers are being used on Ps3, is this true?
hmm.. i think the easiest to do now is get that nadro's patch.. any clue why irrlicht hasn't added support for floating-point buffers yet... i saw that the format is easily available for DirectX render targets
from what i read on the that logluv type blog thingy, it seems integer point buffers are being used on Ps3, is this true?
Hey Blindside, this is good news.
I was playing around with XEffects Luminance and after doing a little here-and-there I stumbled into this paper...
http://www.shaderwrangler.com/publicati ... aready.pdf
... talking about histogram equalization. It also covers the technique used by Valve why they sample the last frame.
Finally! I get it.
I was playing around with XEffects Luminance and after doing a little here-and-there I stumbled into this paper...
http://www.shaderwrangler.com/publicati ... aready.pdf
... talking about histogram equalization. It also covers the technique used by Valve why they sample the last frame.
Finally! I get it.
I've been messing around with this and I have a question. All I want are shadows, so is there any way to use your shadow mapping *without* affecting how my models look? For instance, my main character models looks a bit more blurry (I believe due to your shaders, which is a cool effect, but I am not sure if my artists will be too fond of it). So my question is, how do I just implement the shadows and nothing else, if that's possible?
You have to set the correct ScreenRTT resolution in the constructor. It is blurry by default because I am using a 512x512 rtt (I think?). Try playing around with the value, set it higher than the driver's size if it looks better that way. I heard twice the actual screen res is good, should give you some AA too.
Cheers
Cheers
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Maybe i got a solution, but in exchange, i have a question . The blurry look is because of the resolution of the RTT, that is right, but the solution is not only to increase the RTT resolution, but also, clipping the rendering so it is exactly of the resolution of the screen. See this code, it renders to the half of the resolution in the texture (400x300).
This is the result of it.
The question comes from the point that i can't render the square exactly over the whole screen. It is highly inspired in yout CScreenQuad class, but for some reason i don't figure, why it doesn't render correctly.
Code: Select all
CScreenOverlay::CScreenOverlay(video::IVideoDriver *driver){
Material.Wireframe = false;
Material.Lighting = false;
Material.ZWriteEnable = false;
//Material.setFlag(irr::video::EMF_BILINEAR_FILTER,false);
Vertices[0] = video::S3DVertex( 1.0,-1.0, 0.0, 0,0,1,video::SColor(255,255,255,255), driver->(getScreenSize().Width/2)/1024.0,(driver->getScreenSize().Height/2)/1024.0);
Vertices[1] = video::S3DVertex(-1.0,-1.0, 0.0, 0,0,1,video::SColor(255,255,255,255), 0, (driver->getScreenSize().Height/2)/1024.0);
Vertices[2] = video::S3DVertex(-1.0,1.0, 0.0, 0,0,1,video::SColor(255,255,255,255), 0, 0);
Vertices[3] = video::S3DVertex( 1.0,1.0, 0.0, 0,0,1,video::SColor(255,255,255,255), driver->(getScreenSize().Width/2)/1024.0, 0);
}
void CScreenOverlay::render(video::IVideoDriver *driver)
{
u16 indices[] = {0,1,2,3};
driver->setMaterial(Material);
driver->setTransform(video::ETS_VIEW, core::matrix4());
driver->drawIndexedTriangleFan(&Vertices[0], 4, &indices[0], 4);
}
video::SMaterial& CScreenOverlay::getMaterial(u32 i)
{
return Material;
}
.
.
.
driver->setRenderTarget(RT0);
driver->setViewPort(core::rect<s32>(0,0,resolution.Width/2,resolution.Height/2)); //clip to useful resolution ;) good to use big render to texture textures
//and don't waste time rendering bigger than the screen
smgr->drawAll(); //render here
driver->setRenderTarget(0); //set the Screen to the rendering
driver->setViewPort(core::rect<s32>(0,0,resolution.Width,resolution.Height));//set the Viewport safely
smgr->drawAll(); //render
Rect->CScreenOverlay::render(driver); // try to render the square overlay
.
.
.
The question comes from the point that i can't render the square exactly over the whole screen. It is highly inspired in yout CScreenQuad class, but for some reason i don't figure, why it doesn't render correctly.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt