If I understand correctly,
dPdS and dPdt in the Shading context are the tangents
of a point on a surface relative to the parametric s and t coordinates.
And the global variable N can also be represented
as a cross(dPdS and dPdt) ?????
It would be nice to have global variables dPds and dPdt
in the VEX SOP context, they would be very useful while
working with NURBS curve/surface.
Currently to calculate them I use “AttribCreate SOP” with “primduv” expression:

for dPds:
x: primduv(“../” + opinput(“.”, 0),$PR,“P”,0,$MAPU,$MAPV,1,0)
y: primduv(“../” + opinput(“.”, 0),$PR,“P”,1,$MAPU,$MAPV,1,0)
z: primduv(“../” + opinput(“.”, 0),$PR,“P”,2,$MAPU,$MAPV,1,0)

for dPdt:
x: primduv(“../” + opinput(“.”, 0),$PR,“P”,0,$MAPU,$MAPV,0,1)
y: primduv(“../” + opinput(“.”, 0),$PR,“P”,1,$MAPU,$MAPV,0,1)
z: primduv(“../” + opinput(“.”, 0),$PR,“P”,2,$MAPU,$MAPV,0,1)

However, the object has to have uv coordinates.
Which ones should I use?
(Texture SOP with a “uniform spline” texture type?)
Is there some direct way to access the parametric s and t directly
in the expressions…
S and t are the “build in” surface property, right?

AndrewVK
If I understand correctly,
dPdS and dPdt in the Shading context are the tangents
of a point on a surface relative to the parametric s and t coordinates.

Yes; they are tangents, and they are “aligned” with the parametric UVs. As Mark E. explained to me recently though, they are not derivatives (of P wrt. u and v), but that doesn't matter here.

AndrewVK
And the global variable N can also be represented
as a cross(dPdS and dPdt) ?????

Yes. Or, more properly: cross(dPds/Du(s),dPdt/Dv(t))

AndrewVK
It would be nice to have global variables dPds and dPdt
in the VEX SOP context, they would be very useful while
working with NURBS curve/surface.

Yes, it would be nice
I can see why it's not there though.
In the shading context, the renderer is always examining a little “neighbouhood” of the surface(s). How big this patch is, depends on the shading rate (among other things), but it will never be a single point sample. As a result, Mantra can tell how s and t (and any other variable) changes within this tiny patch, by evaluating the shader at (at least) the corners, and so can calculate how any other var has changed relative to those two.
This is not true for the other contexts. There's no process scanning the surface for you.

AndrewVK
Currently to calculate them I use “AttribCreate SOP” with “primduv” expression:
<snip>
S and t are the “build in” surface property, right?

What you're doing seems like just about the only way to do it (AFAIK).
And yea, Uniform Spline usually works OK… but I know what you mean: Just give me the real uv's please!!
There *are* those other two cryptic functions unituv() and realuv(), but they both *take* real- or unit-uv's as parameters! … and we keep chasing our tail….(BTW: have you ever found any use for unituv() or realuv() in any context? .. I'm starting to suspect SESI just put them there as a little joke: “you want unit parametric uv's? HA! You'll first need to give me the *REAL* parametric uv's! MUUUAAAAHAHAHAHAH!”)

I think this calls for an RFE:
The sotware *knows* what the parametric UVs are for any point/vertex. Could we please get this as another standard point/vertex variable? – not asking for dPd-anything; just plain ol' parametric uv's.

OTOH, maybe it's already there in 6.0 and I just haven't seen it :roll: