How to interpret output position values of Geometry node












1












$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)?



enter image description here



shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}


enter image description here



enter image description here










share|improve this question











$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
    3 hours ago
















1












$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)?



enter image description here



shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}


enter image description here



enter image description here










share|improve this question











$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
    3 hours ago














1












1








1





$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)?



enter image description here



shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}


enter image description here



enter image description here










share|improve this question











$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)?



enter image description here



shader Inspector(float input=0,output color debug=0)
{
debug = input;
printf("n");
printf("%f" , debug );
}


enter image description here



enter image description here







nodes osl






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 4 hours ago







Oleksiy Plotnyts'kyy

















asked 5 hours ago









Oleksiy Plotnyts'kyyOleksiy Plotnyts'kyy

355




355












  • $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
    3 hours ago


















  • $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
    3 hours ago
















$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
3 hours ago




$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
3 hours ago










2 Answers
2






active

oldest

votes


















2












$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);
}





share|improve this answer









$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
    2 hours ago






  • 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
    2 hours ago



















2












$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.






share|improve this answer











$endgroup$













  • $begingroup$
    It doesn't give any output with vector type now.
    $endgroup$
    – Oleksiy Plotnyts'kyy
    3 hours ago












  • $begingroup$
    Ahh.. so that's what the cast from point to float is doing..I couldn't work it out...
    $endgroup$
    – Robin Betts
    2 hours ago






  • 2




    $begingroup$
    @OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
    $endgroup$
    – Secrop
    2 hours ago











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
});


}
});














draft saved

draft discarded


















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









2












$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);
}





share|improve this answer









$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
    2 hours ago






  • 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
    2 hours ago
















2












$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);
}





share|improve this answer









$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
    2 hours ago






  • 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
    2 hours ago














2












2








2





$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);
}





share|improve this answer









$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);
}






share|improve this answer












share|improve this answer



share|improve this answer










answered 3 hours ago









Robin BettsRobin Betts

7,0771628




7,0771628












  • $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
    2 hours ago






  • 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
    2 hours ago


















  • $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
    2 hours ago






  • 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
    2 hours ago
















$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
2 hours ago




$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
2 hours ago




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
2 hours ago




$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
2 hours ago













2












$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.






share|improve this answer











$endgroup$













  • $begingroup$
    It doesn't give any output with vector type now.
    $endgroup$
    – Oleksiy Plotnyts'kyy
    3 hours ago












  • $begingroup$
    Ahh.. so that's what the cast from point to float is doing..I couldn't work it out...
    $endgroup$
    – Robin Betts
    2 hours ago






  • 2




    $begingroup$
    @OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
    $endgroup$
    – Secrop
    2 hours ago
















2












$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.






share|improve this answer











$endgroup$













  • $begingroup$
    It doesn't give any output with vector type now.
    $endgroup$
    – Oleksiy Plotnyts'kyy
    3 hours ago












  • $begingroup$
    Ahh.. so that's what the cast from point to float is doing..I couldn't work it out...
    $endgroup$
    – Robin Betts
    2 hours ago






  • 2




    $begingroup$
    @OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
    $endgroup$
    – Secrop
    2 hours ago














2












2








2





$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.






share|improve this answer











$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.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 hours ago

























answered 3 hours ago









SecropSecrop

1,893614




1,893614












  • $begingroup$
    It doesn't give any output with vector type now.
    $endgroup$
    – Oleksiy Plotnyts'kyy
    3 hours ago












  • $begingroup$
    Ahh.. so that's what the cast from point to float is doing..I couldn't work it out...
    $endgroup$
    – Robin Betts
    2 hours ago






  • 2




    $begingroup$
    @OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
    $endgroup$
    – Secrop
    2 hours ago


















  • $begingroup$
    It doesn't give any output with vector type now.
    $endgroup$
    – Oleksiy Plotnyts'kyy
    3 hours ago












  • $begingroup$
    Ahh.. so that's what the cast from point to float is doing..I couldn't work it out...
    $endgroup$
    – Robin Betts
    2 hours ago






  • 2




    $begingroup$
    @OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
    $endgroup$
    – Secrop
    2 hours ago
















$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
3 hours ago






$begingroup$
It doesn't give any output with vector type now.
$endgroup$
– Oleksiy Plotnyts'kyy
3 hours ago














$begingroup$
Ahh.. so that's what the cast from point to float is doing..I couldn't work it out...
$endgroup$
– Robin Betts
2 hours ago




$begingroup$
Ahh.. so that's what the cast from point to float is doing..I couldn't work it out...
$endgroup$
– Robin Betts
2 hours ago




2




2




$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
2 hours ago




$begingroup$
@OleksiyPlotnyts'kyy, ohh, osl optimizations.. I'm changing the script ;)
$endgroup$
– Secrop
2 hours ago


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Callistus I

Tabula Rosettana

How to label and detect the document text images