Source Shader Editor, a WYSIWYG shader editor from our friend, Biohazard. Or, that "dino mod guy." - Games

It's not meant to be grass i think, it's just spiky parallax. [editline]1st August 2011[/editline] Of course parallax grass can be made.

What's the texture name of the rock?

Why is parallax grass a bad idea? performance or what?

[QUOTE=RichyZ;31457336]mainly how it looks nothing like grass, but still better than a flat texture with sprites on it performance-wise, parallax is around bumpmapping correct me if im wrong[/QUOTE] I think Parallax I think this: [img]http://www.awingsoft.com/screenshots/rockwall2_parallax.jpg[/img]

[QUOTE=glitchvid;31457474]I think Parallax I think this: [img]http://www.awingsoft.com/screenshots/rockwall2_parallax.jpg[/img][/QUOTE] Yes, the example is parallax too, and yes it's supposed to be grass. But regular POM doesn't have the edge silhouetting, so it looks shit on corners.

That is seriously god damn impressive.

if it works on uneven surfaces, then i'll be interested

[QUOTE=RichyZ;31457336] performance-wise, parallax is around bumpmapping correct me if im wrong[/QUOTE] really?

I don't know if you're wrong

Slight technicality, but that's not parallax mapping. It's actually a step up called relief mapping. Parallax mapping - Parallax Occlusion or otherwise - cannot, in any way, change the silhouette of the texture/brush/model it's on. Relief mapping adds actual depth to the texture (look at the rocks against the wood to see what I mean). It's essentially taking slices of a displacement mapped model and laying them one on top of the other to create real depth. Think of a fur shader and you've got the right idea of what this is doing. EDIT: I really need to download this. It just gets better and better, and I've always wanted to know how to code/write up shaders.

[QUOTE=OpethRockr55;31461498]Slight technicality, but that's not parallax mapping. It's actually a step up called relief mapping. [b]Parallax mapping - Parallax Occlusion or otherwise - cannot, in any way, change the silhouette of the texture/brush/model it's on.[/b][/QUOTE] [url=http://www.inf.ufrgs.br/~oliveira/pubs_files/Policarpo_Oliveira_RTM_multilayer_I3D2006.pdf]that's where you're wrong[/url] [media]http://www.youtube.com/watch?v=W3aoQpECaU0[/media] [editline]31st July 2011[/editline] i'm pretty sure the video and the .pdf detail two entirely different techniques to solving this, but regardless, it's possible [editline]31st July 2011[/editline] technically it COULD be considered an alternative to tessellation in some contexts, but i'm ninety-nine percent positive tessellation would run way better

[QUOTE=Aurora93;31462327][url=http://www.inf.ufrgs.br/~oliveira/pubs_files/Policarpo_Oliveira_RTM_multilayer_I3D2006.pdf]that's where you're wrong[/url][/QUOTE] This is where you didn't read the second half of my post: [QUOTE][B]Relief mapping adds actual depth to the texture[/B] (look at the rocks against the wood to see what I mean). It's essentially taking slices of a displacement mapped model and laying them one on top of the other to create real depth. Think of a fur shader and you've got the right idea of what this is doing.[/QUOTE] Fuck, the two things you posted call it relief mapping. Relief mapping modifies silhouette, parallax does not. That was the point of my post. EDIT: Man, reading that PDF makes my head hurt. I was totally wrong about how they do it, though. I really want to learn this. :saddowns:

Is that dino mod still being worked on?

Relief mapped water? I can see it happening.

someone make a gm_construct with parallax grass

the overall idea behind relief mapping is so painfully simple, anyway [img]http://http.developer.nvidia.com/GPUGems3/elementLinks/18fig03.jpg[/img]

That grass looks great, actually.

[QUOTE=OpethRockr55;31463126]Fuck, the two things you posted call it relief mapping. Relief mapping modifies silhouette, parallax does not. That was the point of my post.[/QUOTE] [media]http://www.youtube.com/watch?v=gcAsJdo7dME&feature=related[/media] no, it can [editline]1st August 2011[/editline] [url]http://developer.amd.com/media/gpu_assets/Dachsbacher-Tatarchuk-Prism_Parallax_Occlusion_Mapping_with_Accurate_Silhouette_Generation(SI3D07).pdf[/url] [editline]1st August 2011[/editline] i'm not even sure what you're trying to say anyway

I hope this gets officially added to the SDK/adapted by Valve.

[QUOTE=Baboo00;31467957]I hope this gets officially added to the SDK/adapted by Valve.[/QUOTE] Valve probably already has their own made but won't ever release it because they use 3rd party code in pretty much every tool they've made the last few years.

[QUOTE=Aurora93;31467878][media]http://www.youtube.com/watch?v=gcAsJdo7dME&feature=related[/media] no, it can[/QUOTE] Huh. Guess I was wrong. I thought that POM was just a modified parallax shader that could deal with overlapping texels, not much more.

[QUOTE=Popbob II;31468069]Valve probably already has their own made but won't ever release it because they use 3rd party code in pretty much every tool they've made the last few years.[/QUOTE] Valve make horrible tools, lets be honest. I doubt they'd ever make something as easy to use as this.

Aurora93 you are missing all the details and caveats about the silhouette techniques you are throwing around here. • The unity shader example you've posted uses a shader wide hack that locks the curvature and tiling level, which makes it completely useless for arbitrary geometry, especially displacements in source. • The crysis example locks the whole texture to normalized coordinates, which again doesn't work with tiled textures at all. • The other examples require special preprocessing on the input geometry before the shader will actually do its job. Furthermore, parallax occlusion mapping solely implements a linear search along the heightmap while relief mapping is defined through using a linear and a binary search with depthbias. Relief mapping itself has nothing to do with silhouettes, the other techniques [I]build upon[/I] that. glitchvid, the example you've posted uses parallax mapping with offset limiting I think, notice the dark edges on the farther stones, the heightmap based offset is completely wrong there. That technqiue is super fast though since it does not use a software ray trace and merely guesses the offset, but it doesn't really work at all, you can take a look at the parallax example in the directx sdk if you want, it also presents this trick.

[QUOTE=Biohazard_90;31469024]Aurora93 you are missing all the details and caveats about the silhouette techniques you are throwing around here. • The unity shader example you've posted uses a shader wide hack that locks the curvature and tiling level, which makes it completely useless for arbitrary geometry, especially displacements in source. • The crysis example locks the whole texture to normalized coordinates, which again doesn't work with tiled textures at all. • The other examples require special preprocessing on the input geometry before the shader will actually do its job. ...[/QUOTE] Hey, I posted my attempt of implementing the sunray post shader a page or so back. I have no idea if I coded it right (VDC says something about 3x3 blur I think? I'm pants-on-head stupid when it comes to shaders), but are the results I'm getting look correct? Also, now that we have arrays, on a scale of 1-10 how hard would a DoF shader be to write given the default limited depthbuffer?

[QUOTE=Foda;31471269]Hey, I posted my attempt of implementing the sunray post shader a page or so back. I have no idea if I coded it right (VDC says something about 3x3 blur I think? I'm pants-on-head stupid when it comes to shaders), but are the results I'm getting look correct? [/QUOTE] Well you still have a lot of stepping in the rays, so you should maybe use stronger blur. The idea is just to run the sunrays shader over a much smaller RT, like _rt_SmallFB0 (I guessed the name right now, might be slightly off). When you use the shader on the full framebuffer it's really a performance killer, even with just 30 samples or whatever I used in the example. When you have the sunrays on that RT (don't combine with the scene just yet) you should blur them in two passes. You can now create two gaussian blur shaders with the array node, something like 9 samples should be fine already. After blurring just draw the RT with UnlitGeneric and $additive over the whole screen. This way it should run much faster, with less or even no stepping artifacts at all, but the rays will naturally be blurry and have less detail. [QUOTE=Foda;31471269]Also, now that we have arrays, on a scale of 1-10 how hard would a DoF shader be to write given the default limited depthbuffer?[/QUOTE] Do you want to have correct near blur that bleeds over to farther geometry? If yes, that would be pretty hard to achieve assuming you want to end up with good quality and speed. But otherwise it should be simple: create two blur shaders that check the depth of each sample so you can stop unwanted color bleeding, then just combine the blurred and unblurred RT based on depth. Or if you want to have only very slight blur you can just draw the whole effect in one pass, maybe even with bokeh like Drew did it. You might still have to draw this single pass onto a half or quarter sized framebuffer though to end up with acceptable performance.

[QUOTE=Legend286;31468357]Valve make horrible tools, lets be honest. I doubt they'd ever make something as easy to use as this.[/QUOTE] Personally i think the chance they will buy or integrate this tool is pretty high, (almost all valves games and software was born this way, they just make hats until somebody makes a cool engine modification and then finish it themselves)

[QUOTE=RichyZ;31478547]if valve integrated this and started doing their own bugfixes/improvements to it, that would be a dream[/QUOTE] So they'll make it super unstable and crash when you try to import the shaders? Sounds good to me.

[QUOTE=Paulendy;31479027]So they'll make it super unstable and crash when you try to import the shaders? Sounds good to me.[/QUOTE] Yeah, why should Valve get to break it when there's been so much work put into it.

[QUOTE=Legend286;31479625]Yeah, why should Valve get to break it when there's been so much work put into it.[/QUOTE] Well to be fair, the particle editor works fairly well. I had to sell my soul to the valve sdk devil for a robot-particle-making-hand but I'd say it was a fair trade. Also, the fact that with every new engine release we see an improved editor really kills me in the inside as some effects would now be x100 easier to make... [QUOTE=Biohazard_90;31472583]Well you still have a lot of stepping in the rays, so you should maybe use stronger blur. The idea is just to run the sunrays shader over a much smaller RT, like _rt_SmallFB0 (I guessed the name right now, might be slightly off). When you use the shader on the full framebuffer it's really a performance killer, even with just 30 samples or whatever I used in the example. When you have the sunrays on that RT (don't combine with the scene just yet) you should blur them in two passes. You can now create two gaussian blur shaders with the array node, something like 9 samples should be fine already. After blurring just draw the RT with UnlitGeneric and $additive over the whole screen. This way it should run much faster, with less or even no stepping artifacts at all, but the rays will naturally be blurry and have less detail. Do you want to have correct near blur that bleeds over to farther geometry? If yes, that would be pretty hard to achieve assuming you want to end up with good quality and speed.[/QUOTE] I think I did use _rt_SmallFB0 (guessing) as I just used the same code valve uses for bloom/DoF(from swarm SDK) but changed out the last part to use the sunray code. I have no idea how to really use RTs and stuff, but that's something I can learn on my own. Thanks! [QUOTE=RichyZ;31461389]CORRECT ME IF IM WRONG jeez[/QUOTE] Parallax is built ontop of how normal mapping works, therefore should be just a tad slower. SSBump is actually faster than both of those, and I would assume that POM is just a tad slower than parallax mapping (fast to slow: ssbump>normal>parallax>POM). If you know how SSBumps work, you can think of it as POM = realtime SSBump + parallax + depth checks. Edit: I'll be looking into making bullet holes into parallax'd textures ([url]http://cowboyprogramming.com/2007/01/05/parallax-mapped-bullet-holes/[/url]). If anyone wants my code + textures, I'll be more than happy to post it when I finish it later today.

[QUOTE=Foda;31485790]I think I did use _rt_SmallFB0 (guessing) as I just used the same code valve uses for bloom/DoF(from swarm SDK) but changed out the last part to use the sunray code. I have no idea how to really use RTs and stuff, but that's something I can learn on my own. Thanks![/QUOTE] That sounds good, that part also shows how to use the drawscreenrectangle function or how it was named to render stuff onto a smaller RTs. But the sunray stuff should happen before the blur is done and you should be good to go. [QUOTE=Foda;31485790]Parallax is built ontop of how normal mapping works, therefore should be just a tad slower. SSBump is actually faster than both of those, and I would assume that POM is just a tad slower than parallax mapping (fast to slow: ssbump>normal>parallax>POM). If you know how SSBumps work, you can think of it as POM = realtime SSBump + parallax + depth checks.[/QUOTE] All the parallax mapping stuff that uses software ray traces is pretty slow actually, much slower than just bumpmapping or the cheap parallax trick. Of course that's dependent from how many samples you use etc, so in the end it's up you. [QUOTE=Foda;31485790]Edit: I'll be looking into making bullet holes into parallax'd textures ([url]http://cowboyprogramming.com/2007/01/05/parallax-mapped-bullet-holes/[/url]). If anyone wants my code + textures, I'll be more than happy to post it when I finish it later today.[/QUOTE] I'll warn you that you should test those firstly on surfaces with bumpmapping enabled. Sadly decals appear to only have valid tangentspace data on those. But it's possible to use the screen derivatives to build more or less precise tangentspace vectors for the other cases.