How to determine current poly in shader?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/02/2003 at 02:51, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 8.012
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;---------
Hi,
In a channel shader, I want to know which polygon of which object is currently being rendered (for poly objects).'cd->vd->p' gives me the current 3D location of the point being rendered, but can I find out which object and which poly this is from?
Also, 'cd->vd' can be NULL. In practice, is it ever NULL except when rendering material previews in the material editor windows?
Thanks for any help.
Cheers - Steve
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/02/2003 at 05:22, xxxxxxxx wrote:
VolumeData gives you everything, 'lhit' is the global polygon ID, be aware, this is NOT the same as the polygon ID from the original object, during render all polygon data is "cleaned", removing bad polygons and triangulating any non-planar/convex polygons. You can find out the local polygon ID (for the RayObject) using Obj_to_ID(), this gives you the global polygon ID offset, so the local is just:
vd->lhit-vd->Obj_to_ID(vd->op)
As for cd->vd==NULL, you should always check this kind of link, you never know when/if it may change, if you need vd, just return immediately if it is NULL.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/02/2003 at 06:13, xxxxxxxx wrote:
Aha, excellent. Thanks for the tip off!
So once I've got the local poly offset as you describe, I can presumeably then get to the raypoly using:
RayPolygon *poly = vd->op->vadr + localOffset;
The vertex indices are:
poly->a poly->b poly->c poly->d
And the corresponding (camera space?) vertex coords are in:
Vector *point = vd->op->padr;
Also, I've just noticed:
BaseObject* obj = vd->op->link;
gives me a link to the original object. Excellent.
The only thing that I can't see is how I find out what the polygon ID number was in the original object (prior to 'cleaning'). Is this available anywhere?
Thanks for your help.
Cheers - Steve
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/02/2003 at 12:30, xxxxxxxx wrote:
The RayPolygon is just the same as the normal Polygon, so you'd use vd->op->vadr[ply] where 'ply' is the ID for the local RayObjects polygon.
The points are world space, so you'd have to use the RayCamera (function in VolumeData to get it).
The RayObject to original object link is very useful (for getting tags and such), but you shouldn't count on it, always check !=NULL, generally it is set, but if you use it, again as with the vd!=NULL, check at the start, exit if NULL.
There is no way to get back to the original polygon ID, it would be really handy! it was something I really needed in S&H, I had to rewrite to only use the RayPolygon and RayObject, maybe you can. I'll see if we can have a way to get the original ID, it could be done by repeating the cleaning and tracking which polygons are changed/removed, or maybe better to know the original ID and where it now is but for the current SDK, no, you can't find out. You need to work entirely on the RayObject, provided the original polygons were ok, they will be the same, but since you can't control the original polygons, you have to assume the clean changed the IDs. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/02/2003 at 16:42, xxxxxxxx wrote:
Again, thanks for the helpful info.
Ok, shame we can't get directly back to original poly ID, but as you say, there are potential workarounds, and I can probably manage with the RayPolys.
I agree with what you say about _always_ checking for null pointers (I've done too much programming generally to trust pointers not to be null...).
BTW, My original question about when vd is null was because I was curious as to what situations it happenned in - not because I was planning to rely on it.
Cheers - Steve