How to interpret output position values of Geometry node
$begingroup$
I have a simple sphere with a material. And I want to know how understand information the Geometry node gives. I printed this information through OSL shader. Can somebody please explain to me why the position output is roughly (10 10 10), while the object world location is (0 0 30)?
shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}
nodes osl
$endgroup$
add a comment |
$begingroup$
I have a simple sphere with a material. And I want to know how understand information the Geometry node gives. I printed this information through OSL shader. Can somebody please explain to me why the position output is roughly (10 10 10), while the object world location is (0 0 30)?
shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}
nodes osl
$endgroup$
$begingroup$
How big is your sphere? Is the sphere's origin at its center? Where's the file that shows that problem? Which version of blender are you using? Gosh, so many questions... This is because the Position gives exactly the world coordinates of the point being sampled.
$endgroup$
– Secrop
Jan 27 at 20:37
add a comment |
$begingroup$
I have a simple sphere with a material. And I want to know how understand information the Geometry node gives. I printed this information through OSL shader. Can somebody please explain to me why the position output is roughly (10 10 10), while the object world location is (0 0 30)?
shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}
nodes osl
$endgroup$
I have a simple sphere with a material. And I want to know how understand information the Geometry node gives. I printed this information through OSL shader. Can somebody please explain to me why the position output is roughly (10 10 10), while the object world location is (0 0 30)?
shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}
nodes osl
nodes osl
edited Jan 27 at 19:20
Oleksiy Plotnyts'kyy
asked Jan 27 at 18:58
Oleksiy Plotnyts'kyyOleksiy Plotnyts'kyy
456
456
$begingroup$
How big is your sphere? Is the sphere's origin at its center? Where's the file that shows that problem? Which version of blender are you using? Gosh, so many questions... This is because the Position gives exactly the world coordinates of the point being sampled.
$endgroup$
– Secrop
Jan 27 at 20:37
add a comment |
$begingroup$
How big is your sphere? Is the sphere's origin at its center? Where's the file that shows that problem? Which version of blender are you using? Gosh, so many questions... This is because the Position gives exactly the world coordinates of the point being sampled.
$endgroup$
– Secrop
Jan 27 at 20:37
$begingroup$
How big is your sphere? Is the sphere's origin at its center? Where's the file that shows that problem? Which version of blender are you using? Gosh, so many questions... This is because the Position gives exactly the world coordinates of the point being sampled.
$endgroup$
– Secrop
Jan 27 at 20:37
$begingroup$
How big is your sphere? Is the sphere's origin at its center? Where's the file that shows that problem? Which version of blender are you using? Gosh, so many questions... This is because the Position gives exactly the world coordinates of the point being sampled.
$endgroup$
– Secrop
Jan 27 at 20:37
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
The Position output of the geometry node yields the current shading point (on the surface of your sphere) in World Space. It is the equivalent of the global variable P in OSL.
A lot of the outputs are equvalent to OSL Globals:
Position: point P Position of the point you are shading.
Incoming: The negative of OSL's vector I: The incident ray direction, pointing from the viewing position to the shading position P.
Normal: normal N The surface “Shading” normal of the surface at P.
True Normal: normal Ng The true surface normal at P.(before bump mapping, etc.)
Parametric: float u, v The 2D parametric coordinates of P, as defined for the current object.
The rest as per manual
Your interpretation of point
as float
seems to have unpredictable results..
I've found you have to use the printed variable in some way to prevent the print from being optimized? away.
shader Inspector(
point input = 0.0,
output color debug = 0.0
)
{
debug = input;
//pointless calculation to prevent printf being optimized away
debug[0] = pow(debug[0],1);
printf("%f n",debug);
}
$endgroup$
$begingroup$
Thank you. It seems to be working with vector type as well if we add a pointless calculation. I'm wondering why there is no such optimization with float interpretation.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 21:33
1
$begingroup$
@OleksiyPlotnyts'kyy maybe because, as Secrop points out, the cast frompoint
tofloat
involves a calculation.. the cast between triples just involves passing the components on, unaltered.
$endgroup$
– Robin Betts
Jan 27 at 21:37
add a comment |
$begingroup$
You're turning a vector into a float. So float=(v[0]+v[1]+v[2])/3.
this will give the correct result:
shader Inspector(float xcomp=0, float ycomp=0, float zcomp=0, output color debug=0)
{
debug = (xcomp+ycomp+zcomp)/3;
printf("n");
printf("%f,%f,%f >> %f" , xcomp, ycomp, zcomp, debug);
}
Use the SeparateXYZ and connect each components to the script.
$endgroup$
$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 20:50
$begingroup$
Ahh.. so that's what the cast frompoint
tofloat
is doing..I couldn't work it out...
$endgroup$
– Robin Betts
Jan 27 at 21:31
2
$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
Jan 27 at 21:41
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "502"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fblender.stackexchange.com%2fquestions%2f130073%2fhow-to-interpret-output-position-values-of-geometry-node%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
The Position output of the geometry node yields the current shading point (on the surface of your sphere) in World Space. It is the equivalent of the global variable P in OSL.
A lot of the outputs are equvalent to OSL Globals:
Position: point P Position of the point you are shading.
Incoming: The negative of OSL's vector I: The incident ray direction, pointing from the viewing position to the shading position P.
Normal: normal N The surface “Shading” normal of the surface at P.
True Normal: normal Ng The true surface normal at P.(before bump mapping, etc.)
Parametric: float u, v The 2D parametric coordinates of P, as defined for the current object.
The rest as per manual
Your interpretation of point
as float
seems to have unpredictable results..
I've found you have to use the printed variable in some way to prevent the print from being optimized? away.
shader Inspector(
point input = 0.0,
output color debug = 0.0
)
{
debug = input;
//pointless calculation to prevent printf being optimized away
debug[0] = pow(debug[0],1);
printf("%f n",debug);
}
$endgroup$
$begingroup$
Thank you. It seems to be working with vector type as well if we add a pointless calculation. I'm wondering why there is no such optimization with float interpretation.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 21:33
1
$begingroup$
@OleksiyPlotnyts'kyy maybe because, as Secrop points out, the cast frompoint
tofloat
involves a calculation.. the cast between triples just involves passing the components on, unaltered.
$endgroup$
– Robin Betts
Jan 27 at 21:37
add a comment |
$begingroup$
The Position output of the geometry node yields the current shading point (on the surface of your sphere) in World Space. It is the equivalent of the global variable P in OSL.
A lot of the outputs are equvalent to OSL Globals:
Position: point P Position of the point you are shading.
Incoming: The negative of OSL's vector I: The incident ray direction, pointing from the viewing position to the shading position P.
Normal: normal N The surface “Shading” normal of the surface at P.
True Normal: normal Ng The true surface normal at P.(before bump mapping, etc.)
Parametric: float u, v The 2D parametric coordinates of P, as defined for the current object.
The rest as per manual
Your interpretation of point
as float
seems to have unpredictable results..
I've found you have to use the printed variable in some way to prevent the print from being optimized? away.
shader Inspector(
point input = 0.0,
output color debug = 0.0
)
{
debug = input;
//pointless calculation to prevent printf being optimized away
debug[0] = pow(debug[0],1);
printf("%f n",debug);
}
$endgroup$
$begingroup$
Thank you. It seems to be working with vector type as well if we add a pointless calculation. I'm wondering why there is no such optimization with float interpretation.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 21:33
1
$begingroup$
@OleksiyPlotnyts'kyy maybe because, as Secrop points out, the cast frompoint
tofloat
involves a calculation.. the cast between triples just involves passing the components on, unaltered.
$endgroup$
– Robin Betts
Jan 27 at 21:37
add a comment |
$begingroup$
The Position output of the geometry node yields the current shading point (on the surface of your sphere) in World Space. It is the equivalent of the global variable P in OSL.
A lot of the outputs are equvalent to OSL Globals:
Position: point P Position of the point you are shading.
Incoming: The negative of OSL's vector I: The incident ray direction, pointing from the viewing position to the shading position P.
Normal: normal N The surface “Shading” normal of the surface at P.
True Normal: normal Ng The true surface normal at P.(before bump mapping, etc.)
Parametric: float u, v The 2D parametric coordinates of P, as defined for the current object.
The rest as per manual
Your interpretation of point
as float
seems to have unpredictable results..
I've found you have to use the printed variable in some way to prevent the print from being optimized? away.
shader Inspector(
point input = 0.0,
output color debug = 0.0
)
{
debug = input;
//pointless calculation to prevent printf being optimized away
debug[0] = pow(debug[0],1);
printf("%f n",debug);
}
$endgroup$
The Position output of the geometry node yields the current shading point (on the surface of your sphere) in World Space. It is the equivalent of the global variable P in OSL.
A lot of the outputs are equvalent to OSL Globals:
Position: point P Position of the point you are shading.
Incoming: The negative of OSL's vector I: The incident ray direction, pointing from the viewing position to the shading position P.
Normal: normal N The surface “Shading” normal of the surface at P.
True Normal: normal Ng The true surface normal at P.(before bump mapping, etc.)
Parametric: float u, v The 2D parametric coordinates of P, as defined for the current object.
The rest as per manual
Your interpretation of point
as float
seems to have unpredictable results..
I've found you have to use the printed variable in some way to prevent the print from being optimized? away.
shader Inspector(
point input = 0.0,
output color debug = 0.0
)
{
debug = input;
//pointless calculation to prevent printf being optimized away
debug[0] = pow(debug[0],1);
printf("%f n",debug);
}
answered Jan 27 at 21:09
Robin BettsRobin Betts
7,2071628
7,2071628
$begingroup$
Thank you. It seems to be working with vector type as well if we add a pointless calculation. I'm wondering why there is no such optimization with float interpretation.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 21:33
1
$begingroup$
@OleksiyPlotnyts'kyy maybe because, as Secrop points out, the cast frompoint
tofloat
involves a calculation.. the cast between triples just involves passing the components on, unaltered.
$endgroup$
– Robin Betts
Jan 27 at 21:37
add a comment |
$begingroup$
Thank you. It seems to be working with vector type as well if we add a pointless calculation. I'm wondering why there is no such optimization with float interpretation.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 21:33
1
$begingroup$
@OleksiyPlotnyts'kyy maybe because, as Secrop points out, the cast frompoint
tofloat
involves a calculation.. the cast between triples just involves passing the components on, unaltered.
$endgroup$
– Robin Betts
Jan 27 at 21:37
$begingroup$
Thank you. It seems to be working with vector type as well if we add a pointless calculation. I'm wondering why there is no such optimization with float interpretation.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 21:33
$begingroup$
Thank you. It seems to be working with vector type as well if we add a pointless calculation. I'm wondering why there is no such optimization with float interpretation.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 21:33
1
1
$begingroup$
@OleksiyPlotnyts'kyy maybe because, as Secrop points out, the cast from
point
to float
involves a calculation.. the cast between triples just involves passing the components on, unaltered.$endgroup$
– Robin Betts
Jan 27 at 21:37
$begingroup$
@OleksiyPlotnyts'kyy maybe because, as Secrop points out, the cast from
point
to float
involves a calculation.. the cast between triples just involves passing the components on, unaltered.$endgroup$
– Robin Betts
Jan 27 at 21:37
add a comment |
$begingroup$
You're turning a vector into a float. So float=(v[0]+v[1]+v[2])/3.
this will give the correct result:
shader Inspector(float xcomp=0, float ycomp=0, float zcomp=0, output color debug=0)
{
debug = (xcomp+ycomp+zcomp)/3;
printf("n");
printf("%f,%f,%f >> %f" , xcomp, ycomp, zcomp, debug);
}
Use the SeparateXYZ and connect each components to the script.
$endgroup$
$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 20:50
$begingroup$
Ahh.. so that's what the cast frompoint
tofloat
is doing..I couldn't work it out...
$endgroup$
– Robin Betts
Jan 27 at 21:31
2
$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
Jan 27 at 21:41
add a comment |
$begingroup$
You're turning a vector into a float. So float=(v[0]+v[1]+v[2])/3.
this will give the correct result:
shader Inspector(float xcomp=0, float ycomp=0, float zcomp=0, output color debug=0)
{
debug = (xcomp+ycomp+zcomp)/3;
printf("n");
printf("%f,%f,%f >> %f" , xcomp, ycomp, zcomp, debug);
}
Use the SeparateXYZ and connect each components to the script.
$endgroup$
$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 20:50
$begingroup$
Ahh.. so that's what the cast frompoint
tofloat
is doing..I couldn't work it out...
$endgroup$
– Robin Betts
Jan 27 at 21:31
2
$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
Jan 27 at 21:41
add a comment |
$begingroup$
You're turning a vector into a float. So float=(v[0]+v[1]+v[2])/3.
this will give the correct result:
shader Inspector(float xcomp=0, float ycomp=0, float zcomp=0, output color debug=0)
{
debug = (xcomp+ycomp+zcomp)/3;
printf("n");
printf("%f,%f,%f >> %f" , xcomp, ycomp, zcomp, debug);
}
Use the SeparateXYZ and connect each components to the script.
$endgroup$
You're turning a vector into a float. So float=(v[0]+v[1]+v[2])/3.
this will give the correct result:
shader Inspector(float xcomp=0, float ycomp=0, float zcomp=0, output color debug=0)
{
debug = (xcomp+ycomp+zcomp)/3;
printf("n");
printf("%f,%f,%f >> %f" , xcomp, ycomp, zcomp, debug);
}
Use the SeparateXYZ and connect each components to the script.
edited Jan 27 at 21:44
answered Jan 27 at 20:40
SecropSecrop
1,913614
1,913614
$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 20:50
$begingroup$
Ahh.. so that's what the cast frompoint
tofloat
is doing..I couldn't work it out...
$endgroup$
– Robin Betts
Jan 27 at 21:31
2
$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
Jan 27 at 21:41
add a comment |
$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 20:50
$begingroup$
Ahh.. so that's what the cast frompoint
tofloat
is doing..I couldn't work it out...
$endgroup$
– Robin Betts
Jan 27 at 21:31
2
$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
Jan 27 at 21:41
$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 20:50
$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
Jan 27 at 20:50
$begingroup$
Ahh.. so that's what the cast from
point
to float
is doing..I couldn't work it out...$endgroup$
– Robin Betts
Jan 27 at 21:31
$begingroup$
Ahh.. so that's what the cast from
point
to float
is doing..I couldn't work it out...$endgroup$
– Robin Betts
Jan 27 at 21:31
2
2
$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
Jan 27 at 21:41
$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
Jan 27 at 21:41
add a comment |
Thanks for contributing an answer to Blender Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fblender.stackexchange.com%2fquestions%2f130073%2fhow-to-interpret-output-position-values-of-geometry-node%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
How big is your sphere? Is the sphere's origin at its center? Where's the file that shows that problem? Which version of blender are you using? Gosh, so many questions... This is because the Position gives exactly the world coordinates of the point being sampled.
$endgroup$
– Secrop
Jan 27 at 20:37