@pspeed It works if I just return norm… or don’t call the function at all. And yeah 
ATI card
If it were me, I’d keep including a little more code each time until I could figure out what part of that function causes the link failure.
Nothing jumps out at me except that if the axis is not one of 0, 1, or 2 then the dist and coeff never get set. I don’t know if these messes with the code optimizer in some strange way.
@pspeed Couple final questions so I can attack this again with a little more understanding…
Do you know off hand if normal vectors are limited to -1.0 to 1.0? I would think that it wouldn’t matter one way of the other… but it might.
And lastly… whats the best way to debug a shader? Is there any way of seeing variable values while the shader is in use?
@t0neg0d said:
@pspeed Couple final questions so I can attack this again with a little more understanding...
Do you know off hand if normal vectors are limited to -1.0 to 1.0? I would think that it wouldn't matter one way of the other... but it might.
I don't understand the question. A vector can have any three values including NaN,Nan,Nan. A normalize()'ed vector will always be of length 1 but the x,y,z values could be anything positive or negative as long as the vector is of length 1.
@t0neg0d said:
And lastly... whats the best way to debug a shader? Is there any way of seeing variable values while the shader is in use?
If you have something failing to compile, I usually just try removing stuff and adding it back until I zero in on the line that fails. (Though nvidia cards are nice enough to give me real errors in most case. :P)
Otherwise, the universal trick is to set the pixel color to some value based on a condition. For example, if I wonder what my dot product is, I can set the gl_FragColor.r to something based on the values... or whatever.
@pspeed The normals question was stated reallllly poorly, due to my lack of overall understanding of how a vertex’s normal vector actually looks (values wise). I was assuming they were directional vectors where the value (no matter how far you increment or decrement it) is cyclical at some point (i.e. a directional vector of (0,-1,0) and (0,-5,0) are going to yield the same results… um… or does it /cry).
I have a feeling this assumption was WAY off base and I have a bit more reading to do.
A vector is a vector. They get no special treatment just because the engine calls them "normal"s. After all, you can stick things in a color buffer that aren’t colors. (Mythruna uses its color buffer for lighting values.)
You can send whatever three crazy values you want in a vertex’s normal attribute.
1 Like
@pspeed Exactly!! That’s why I am pulling my hair out over this stupid error /cry. Here is what happened when I tried to limit the code and narrow down the exact line. It came down to being able to leave every line in place, but if I pass the values I am calculating back (whether I dummy them up and just pass in values that are garbage or use the calc I “think” should work) the shader “fails to link”. I guess my next attempt will be to return vec3(inNormal.x,inNormal.y,inNormal.z) and just see if it just boils down to my shader hates me. lol
Then it’s not necessarily that function that’s the problem but something that is calling it.
Where you call it, reset the return value to something you know works… and then move that reset down until you see the problem again or something.
…though it does occur to me that your function does not use “in” for its parameters. I don’t know if that’s significant or just my rampant paranoia.
@t0neg0d said:
EDIT: I should also mention, info on the fundamental workings of shaders is NOT readily available on the web. Trying to find an answer to simple concepts like what texture coordinates actually are (0-1??! Makes sense now.. but...), is next to impossible to find... so ask here. Also, I'm still lost on a TON of of these... but trial and error/asking those who know has been a good thing.
I've found that too... I still have no clue how they work.
I wonder, now that you've broken through the shell, have you considered writing about what you've learned? If you were to write a little "shaders for idiots" guide on a web site somewhere I am sure it would be useful to a lot of people (and since there's not much else there on the topic, I dare say you could make a little money from ads revenue to make it worth your while too).
@monkeychops said:
I wonder, now that you've broken through the shell, have you considered writing about what you've learned? If you were to write a little "shaders for idiots" guide on a web site somewhere I am sure it would be useful to a lot of people (and since there's not much else there on the topic, I dare say you could make a little money from ads revenue to make it worth your while too).
So theres even more reason to read and extend our wiki, it seems the best place to get this kind of information. Sadly few of the people that complain about "missing" information in the wiki about general topics update it after they learned about it one way or the other. Anyway most of whats being discussed here is described in the wiki already. Make sure you do not miss the main primers and links, the role wiki is set up in a way that you can successively learn about 3d development to a point where you should be able to go on by yourself with enough information to do sensible google etc. research. If only you actually read the wiki instead of looking for a solution for a current idea or problem.
@normen I’d be more then happy to contribute in this way, I’m just afraid of passing along my misconceptions in the process Do others review new/changed Wiki pages to ensure the information is accurate?
If you want you can add a post in the “Documentation” forum for somebody to check an extended article or something.
Also, if you want to do anything more than basic shader tweaks (and even then), you’d be almost crazy not to have the Orange Book handy:
http://www.amazon.com/OpenGL-Shading-Language-Randi-Rost/dp/0321637631/ref=sr_1_1?ie=UTF8&qid=1329929412&sr=8-1
I keep mine within arm’s reach.
For something as potentially complex as directly programming custom hardware, it’s good to have real documentation all in one place.
I unfortunately do not have the book yet, however, I have downloaded all of the example shaders and use them as reference points. Book is on it’s way though!
And thanks normen! I’ll start working on this and once I have something that is useful (and correct) I’ll post it there!
Omg… my brain hurts… but the basic understanding and implementation of recalculating normals after deformation using an Inverse Jacobian Matrix is finally working. Thank you to everyone who took a look at my posted code… especially @pspeed for pointing out that the error was not in the recalc method, but something after the fact.
Anyways, here is a video of the normals being updated in the vertex shader after a single deformation. I still have the a hurdle to overcome with placement of the normals recalculation. It needs to happen after the potential 3 deformations and then also needs to compound the output from calculating normals against the X axis deform… into the Y axis deform… and finally into the Z axis deform (if they apply) to work properly for multiple deformations.
Yeah… brain is still hurting… but I am really excited about the potential here.
http://youtu.be/LFhW2d6miNg
5 Likes
o/ you made…a blob…
Very nice work 
Not just any ol’ normal blob… oh wait…
Marvellous!
@normen said:
Its.. Peter Griffins belly xD
I could not find an english version of this one but the point is still there:
http://www.youtube.com/watch?NR=1&feature=endscreen&v=kOHXZpyAfLo
In English, "Woohoo! Look at that blubber fly!"