Hi everyone
I recently more or less finished my generic BRDF shader for maya. There's other features that might be interesting but then it will start to be a little messy. I was thinking of building up another shader specifically for environment purpose. That might be useful, especially maybe with the unearthly challenge coming up (seems that unlike DW shader and offline rendering are accepted right?).
So I was wondering what features would be useful. Here's a list of ideas. Please tell me which ones would make sense and don't hesitate to add requests
- multi point lights with attenuation
- directional light (sun)
- cubemap ambient ?
- hemispheric ambient ?
- textures blending using vertex color
- detail maps
- auto uvs generation (according to world position)
- light map on separate uv set
- vertex color lighting
- radiosity normal mapping ?
- relief mapping ?
- ...
thx for your feedback
![:) :)](https://polycount.com/plugins/emojiextender/emoji/twitter/smile.png)
Replies
bugo: there's no way you can automaticly link every lamp in the scene. that's what Highquality rendering is for. But you can link your lights attributes to the shader. For example for the shader to use the actual light color. But honestly I won't bother trying to emulate every type of light in maya and there's no way I know you can have unlimited number of lights. I'll stick with points and a directional I think. Doing spots is nothing difficult really, but you can't hide unused parameters in cgfx so all of these will be displayed at all time (position + direction + color + attenuation + falloff * number of lights). Is there really a big need for spots rather than points? My idea was more for outdoors actually, because dynamic lighting of interiors would require way more lights or a baked solution.
nice portfolio btw bugo
In old days I worked in a company that I really like the way I could paint in the terrain 8 textures and mix them out. I just couldnt use 5 or more textures in a vertex. But I think its very good to have 4 in a vertex, I just dont know exactly how the programmer made 8 textures in the same mesh. I think that when the face had more than 4 textures it creates a new material to blend with. I dont know if thats possible, but I am also sure its very rare a game needing 4 or more blendings, right?
Thanks
Brice, I don't know how Maya's vertex channels work, but you could probably two arbitrary channels instead of vertex color... that way you could support nx4 amount of textures. And paint vertex color as well, to multiply into the texture.
I'd also be wary of spending too much time on pipeline-dependent features, such as radiosity normal mapping... very cool stuff, but it requires radiosity normal maps and a setup to support them. People would probably much rather have the rest of the very useful stuff you've mentioned.
You should probably do Parallax Occlusion Mapping instead of Relief (at least the poliocarpo implementation that's been around for a few years). I have the good ATI Tartarchuk implementation of POM on my website if you need reference (actually, I'd recommend using it, I have it in a nice functionalized form already).
I get your point of the storage of floats. But the way you edit these vertex values are API related. For example I already need to 'normalize' those values in the VS because maya doesn't do it on its own (which is logic for colors). Even then, problem arise:
Imagine grass is driven by red channel, rocks by green and sand by alpha. If you paint rocks it will automatically replace the grass, because a color replace the other. The normalization will then make a balance between those two channels. But if you paint alpha your vertex can at the same time be red AND transparent. This means that whatever color you paint, the map will always appear at least 50% sand, because the color doesn't replace the alpha value. It would work if we could specify RGBA presets rather than RGB ones.
It will probably be confusing enough. Even if I got your point we're bound by maya usability
Vertex channels can be linked the way you want, if It would make more sense for a certain type of data you could use UV sets instead of color sets for example. You can easily have more than one vertex set, which is why I was planning on having both blend and color (per vertex ao or illumination bake or anything).
RNM is just about fun and exploring stuff, I'm not completely altruistic sorry :P
I'm interested in your POM solution. I don't have max here so I can't test it but i'd be glad to have a chat with you about it (even concerning the license I'm using for the release). I did add you on msn but you haven't showed up yet
cheers
I don't think it's that silly since it's already included in my first brdf shader :P
http://mentalwarp.com/~brice/download/GenericBRDF_2_BETA3.cgfx
I have a more recent version at home but the checker behavior is unchanged, does that correspond to what you are asking for? There is a checkbox and a field (should be set to 512, 1024, etc ). It would be tricky to display a procedural way of showing the direction of the tangent space, but its easy for consistency of texel density. There's a few tools to check it in maya though (shade UVs etc).
I might integrate that feature as well if it's not too much of a mess :P
What I said about 'telling if it's the right way up' just meant having something like an R or something on the checker-map itself (so you can see if the uv's need to be flipped). I don't really know what it is you said, but I imagine it wasn't what I meant
When you say 'should be set to 512, 1024 etc', do you mean you need to tell the shader what resolution the map should be, or is there some way for it to just use an appropriately sized checker by checking (teehee, a pun) which size the applied texture is?
Anyway, I'm already excited enough about this if it'll have the features you listed yourself
The checker is generated procedurally. It's quite easy to generate squares, it's far more difficult to produce a "R" out of mathematical functions. To check the uv orientation you should rather use maya's built-in tools or a bitmap texture
I didn't do the max port so I can't really help you with that sorry.
The shader is on its way I've been working on an easily expendable multilamp shader, more to come soon
The shader supports a lot of feature already. It is build around the ability to blend textures, so it's basically done for a terrain. I'll do a 'light' version later on so that you can use the same lighting solution on props.
Here's a rough sample of texture blending, I'll do a nicer one for the release
The shader supports 2 lamps at the moment but it should be easily scalable to fit your needs (in your card's pixel shader capacity)
Here is the current parameters layout
There is no RNM, POM, specular attenuation, cubemaps nor checker at the moment.
You can try it here
http://www.mentalwarp.com/~brice/download/TerrainBlend01_BETA.cgfx
I remind you that that:
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License http://creativecommons.org/licenses/by-sa/3.0/
thanks for respecting it
I use maya 2008 and a 8800, I haven't tested on another hardware yet. This might be just a parameters issue tough.
EVGA geforce 8800gts 640mb
Windows XP x64
Maya 2008 x64
With you configuration you shouldn't have any problem, but be sure to check if all the parameters are set properly, for some reason maya doesn't care at all of the default values and sets everything to zero. The shader needs some more 'error management' for this. The more obvious problem is specular power (you shouldn't power by 0). I did correct this on my wip version, keep up the feedback.
You have to make sure the inputs are set up properly, the should be like this (at least for the options you're using - the second uv set for light maps, vertex color etc).
you don't have to fill all the maps, especially since these can be deactivated most of the time, but some basic inputs are of course mandatory (this is a vertex blending shader, so yeah, you should have a vertex color blend set...)
detail texture is on the way.
If you have more problems please be complete: post a screenshot of your parameters and how does the shader look on screen. thx
Btw, i didnt have the time to test it and not get those problems, I will later.
http://www.littleoddity.com/pimp/settings.gif
http://www.littleoddity.com/pimp/screenshot01.jpg
I don't really know what's going on here because your settings seem correct. One thing I am wondering tough: Did you used exactly the same names as I did for the vertex data or did you typed those manually? I just noticed that it doesn't produce any error when these don't correspond anything. If you right clic you should have a list of the available data. In your case you probably just need to set the only vertex color to the blend slot and deactivate the
"use vertex color" checkbox. You can create additional vertex color set in color > color set editor. I also see you have normal maps plugged in but "use normal mapping" is unchecked.
Do you think that someone with access to a copy of ShaderFX could easily transfer this (once you are done) into a Max shader? or does it use too much Maya specific stuff to be compatible?
-Andrew
Thx rube, Hope you'll have some fancy screens to show
I forgot to mention I did a few fixes, but I didn't took time to implement more fancy features yet
http://www.mentalwarp.com/~brice/download/TerrainBlend_BETA2.cgfx
Now i think both systems have their pros and cons, but i really wouldn't consider one better than the other.
And yeah, for your application i'm sure vert based will work just fine, my comments were more general purpose
[edit] Oh ok i see what you're saying, no for example in our game, we have one large continous terrain that covers the entire level. We dont actually have sepperate sections for lower detail, theres just chunks of the level that will naturally have less tesselation because the player isnt allowed to go there. But we still use the same material system on those areas. We use a single grayscale image(1024 or 2048) that blends together 4 different layers.
yeah, it was mentioned, thanks
cgfxShader -e -fx "C:/Documents and Settings/Administrator/My Documents/shaders/TerrainBlend01_BETA.cgfx" cgfxShader1;
// Error: CG ERROR : The compile returned an error. //
// Error: (1) : error C0501: type name expected at token "<"
(1) : error C0000: syntax error, unexpected '<' at token "<" //
// cgfxShaderNode::cgErrorCallBack
// Error: CG ERROR : The compile returned an error. //
// Error: (1) : error C0501: type name expected at token "<"
(1) : error C0000: syntax error, unexpected '<' at token "<" //
// Error: cgfxShader "cgfxShader1" unable to load effect "C:/Documents and Settings/Administrator/My Documents/shaders/TerrainBlend01_BETA.cgfx" //
rube: that's a good first try. I'm glad to see you can get it work
I already tried to reinstall CG sdk and the last directx SDK, samething.
reloading the shader fixes it. The bug only shows up outside the 0-1 uv range, that make me think that it might be some sampler state issue. Maybe once in a while it doesn't use the default parameters, so I might need to specify it.
- At the 3rd texture set it seems its getting incandescent for some reason.
- Not sure I understand lights alpha, if I go higher than 0,001 it dissapear, or I use 0,001 or 0.
- For the lightmap, i cant seem to find it going good, it seems it should be much more multiplied or modulated but its half or even 1/4 of it, not sure why.
I´ll post a shot soon, Thanks! You rock!
here a test I did with both lovely shaders from Brice.
The brdf has been assigned to all props on ground while blender one has been used , as expected , for ground. During texturing and maps assignments, I only ended up with same bugs as Hugo anytime I mapped a specular map. Never had the bug dealing with diffuses or normal maps. So pretty stable, apart with this banding artifact (spec assignment or remapping only).
Saving and reloading the scene always solved the problem in my case.
Vertex AOs and their blend modes is really a tip for optimizing the result.
Didn't loose time in optimizing the ground geo while the rest is. And btw, keeping more geo on ground of course allows more freedom afterwards, which is pretty usefull in this case.
Can't wait to test a more metalic scene, what i'm doing right now. Also with some LM.
Thx Brice for your investment in these code chuncks, and for the real pleasure using the result.
Just in case, i've uploaded some uncompressed turn around HERE. Changed the tubes spec recently (next screens). Yes, I'll have it uploaded on youtube soon Brice.
Otherwise, if you don't want the 150 megs of the uncompressed vid, here are some samples ...
Some tips ...
As we can see on 2nd and 3rd images, transitions between plain dry mud (red/alpha:1) and grass (black/alpha:0) are not that great. A bit of blue between, and we got some nicer and more realistic blending as in the image up here.
Nice to see you down here Hugo, the Damnation's not so far ;o)
isn't that ao a bit too bold?
keep it up
Just as if you made a planar proj from side view, than the plane would show lines.
But nothing hard to solve, save , reload
Like the problems I had with the cg from Ced ... mostly spec/env maps artifacting, which one I got rid of when installing nVidia cg pack.
And yes friend, AO is a bit too bold, in fact I generated 2 vertex occlusions, which ones I then merged. This to hide some minor faulty details, like some seams I was tooooo lazy to correct hehehehe
Glib, sry I'm fucking stooopid having forgotten to mention it has to be re-extensioned as a .avi ;o) (did this to prevent reading of it directly within the browser).
Cheers, and use it guys, it's just a bit of viewport's paradise in it ^^