Jump to content

Post-processing effects test (SSAO/HDR/Bloom)


Recommended Posts

It's a bit laggy on my laptop just by drawing a screen full of grass, though I'm sure a gaming PC can handle this effect with ease.

By the way, I've noticed that the blades of grass are always rendered behind all other objects. Is that a technical limitation or artistic decision?

Link to comment
Share on other sites

I've removed both lines and it's still black.

Are you missing the base texture? It should be the file art/textures/terrain/types/snow grass 2.dds...

By the way, I've noticed that the blades of grass are always rendered behind all other objects. Is that a technical limitation or artistic decision?

Neither. I implemented the grass in like 15 minutes just to see if/how it works and didn't give it much thought. ;)

Link to comment
Share on other sites

Are you missing the base texture? It should be the file art/textures/terrain/types/snow grass 2.dds...

No, I do have it.

Which git commands would you issue to make sure that your working directory is exactly identical to upstream?

Link to comment
Share on other sites


<?xml version="1.0" encoding="utf-8"?>
<terrain>
<textures>
<texture name="baseTex" file="grass1_spring.dds"/>
<texture name="normTex" file="snow grass 2_norm.png"/>
<texture name="specTex" file="snow grass 2_spec.png"/>
</textures>
<material>terrain_norm.xml</material>
</terrain>

ya9R7.png

kN9Sis.jpg

Edited by zoot
Link to comment
Share on other sites

kN9Sis.jpg

Haha, yeah.

We've ruled out the normal/specular code, we've ruled out the textures. What's even left??

Tell you what, it's late here and I'm tired. My brain isn't working. Let's continue this tomorrow and hopefully the answer is obvious and we just can't see it.

Link to comment
Share on other sites

As an aside - For guys who have been around a while (like me) I think there is a level of irony that a windows .exe of your patch hasn't been readily available for testing purposes.

We should make the autobuilder capable of working off Github branches so all these kinds of features can be developed in cooperation with the artists who should use them.

Link to comment
Share on other sites

We should make the autobuilder capable of working off Github branches so all these kinds of features can be developed in cooperation with the artists who should use them.

We could easily, once we fix http://trac.wildfire...om/ticket/1514. The problem is pulling in possibly untrusted code from third party sources, compiling and distributing that EXE, especially if it's some kind of automated process.

On a related note, I've pulled myconid's changes into my local git repo (didn't know it was so easy (y)) and successfully built it on Windows. I have no idea how this could be practically distributed without packaging the whole game, or at least changed EXEs/DLLs and a bunch of other assorted data files (it's probably cleaner to package the whole thing so people can use it independently of SVN). Plus I'd have to fix new files that have been added since the last time myconid' merged from upstream. And there's a few different branches, I'm not sure which one would be best for demonstration.

Link to comment
Share on other sites

We could easily, once we fix http://trac.wildfire...om/ticket/1514. The problem is pulling in possibly untrusted code from third party sources, compiling and distributing that EXE, especially if it's some kind of automated process.

True. Maybe if you all become more keen on using Git one day, someone trusted could maintain a more liberal 'experimental' branch separate from the main trunk - a lot of OS projects seem to do that.

And there's a few different branches, I'm not sure which one would be best for demonstration.

Personally, I would use 'modelmapping' since the normal/parallax stuff seem to have the greatest near-term impact for artists.

Edited by zoot
Link to comment
Share on other sites

Tried your TerrainSwapping branch… Got a weird "blinking texture" problem. Most surfaces blink to white and then normal very rapidly. It looks like it has a link with some sort of alpha problems, because for examples foundations are surrounded by a black square, and texture blending for terrain fails. The trees do wave, and I'm not sure what else should change. It also doesn't happen on everything.

post-9128-0-07380700-1341306298_thumb.jp

I've used the version from your github, changing the premake to SVN version because it crashed. I'm on Mac OS 10.6.8, using an iMac.

Edited by wraitii
Link to comment
Share on other sites

Tried your TerrainSwapping branch… Got a weird "blinking texture" problem. Most surfaces blink to white and then normal very rapidly. It looks like it has a link with some sort of alpha problems, because for examples foundations are surrounded by a black square, and texture blending for terrain fails. The trees do wave, and I'm not sure what else should change. It also doesn't happen on everything.

post-9128-0-07380700-1341306298_thumb.jp

I've used the version from your github, changing the premake to SVN version because it crashed. I'm on Mac OS 10.6.8, using an iMac.

Fixed (the blending problem).

I think the blinking is a separate issue that has to do with the shadowmap.

Edited by myconid
Link to comment
Share on other sites

I looked around a bit. The blinking problem actually comes from the "a_normal" parameter being completely messed up when using glsl on my computer. Even the regular alpha does it. No idea why.

I'll try to see if I can port your glsl shaders to arb, which seems to work.

Link to comment
Share on other sites

I looked around a bit. The blinking problem actually comes from the "a_normal" parameter being completely messed up when using glsl on my computer. Even the regular alpha does it. No idea why.

I'll try to see if I can port your glsl shaders to arb, which seems to work.

So you mean this is a problem even without my changes?

Btw, what's your GPU? a_normal is read in straight from the model files, it shouldn't be messed up...

Link to comment
Share on other sites

That's what I'm saying. It is indeed fairly weird that a_normal is messed up... I'm using a Geforce GT 120, with 256 Mo of vRam.

My macBookAir, running 10.7 (on a Intel HD 3000) doesn't seem to have this problem. Can't tell if it comes from outdated shaders, or the GPU itself.

Edit: Okay, got the specular to work on ARB. Moving on.

Edited by wraitii
Link to comment
Share on other sites

That's what I'm saying. It is indeed fairly weird that a_normal is messed up... I'm using a Geforce GT 120, with 256 Mo of vRam.

My macBookAir, running 10.7 (on a Intel HD 3000) doesn't seem to have this problem. Can't tell if it comes from outdated shaders, or the GPU itself.

I'm a little relieved that this isn't my fault. ;)

By looking at your screenshot I'd have thought that whatever is malfunctioning is either in the driver or in some alpha-testing or depth-function related config in the engine. How do you know the problem is with a_normal? That isn't used for alpha blending/testing, it's used for things like lighting.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...