which way to support facevarying values for meshes/subdivs?

[iqch]

setting vertex.texcoord means just a pair for each mesh point. Of course we can split mesh to parts according to texture islands, but it will not work for subdivs (ok, I know, that it will work, making extra poly-stripes and disabling boundaries interpolation, but it is too much fun and not an universal solution)

[johguenther]

Currently OSPRay only supports a single topology, i.e. if a vertex position is shared also its attributes are shared between faces. For meshes you sketched the workaround: not sharing the vertex. But you need that mainly for SubDs? SubD support in OSPRay is a first step, thus we should add support for multiple typologies (concretely an optional index.texcoord) in a further iteration? What about color?

[iqch]

All varying parameters can be passed in facevarying mode - color, normals, textures. it is a standard feature now. Of course, subdivs are popular and useful visual primitives, for modern renderer is better to pay attention this fact. Why are you keep away from OpenSubdiv?

[carsonbrownlee]

while it doesn't sound like you are using ptex, it is supported in OSPRay through the ptex module, https://github.com/ospray/module_ptex. Embree's subd params are compatible with opensubdiv's. You could map the output of OpenSubdiv to a quadmesh if you are already using OpenSubdiv, but it would likely make more sense to use the grid primitive which hasn't been exposed through OSPRay yet, though will likely be put in soon. Fortunately OSPRay is pretty easy to extend through modules...

[iqch]

1. ptex module published is for obsolete API, I have some adventures compiling it for OSPRay2, but still didn't see its using result, may be later. Possible, my version doesn't work. Noone can say.
2. Sorry, but module developement is less documented , than it should be.
3. Even if I use opensubdiv - nothing can force embree use vertex varying data as facevarying. You should implement them in embree anyway.

[johguenther]

Embree does support face-varying data: https://www.embree.org/api.html#face-varying-data

And I think OSPRay should as well, i.e. it's SubD geometry should be OpenSubDiv compatible. Internally we will use Embree's grid primitive, but hide that from the user (i.e., not expose as own geometry, unless there are compelling reasons (maybe displacement mapping?)). This means adding optional parameters

• uint[] index.texcoord (defaulting to index if not present)
• int mode.texcoord (defaulting to mode if not present)
• uint[] index.color (defaulting to index if not present)
• int mode.color (defaulting to mode if not present)

Does this look ok?

[iqch]

It looks nice (except of normal, but it is very rare usecase), but is it implemented in OSPRay? I look into its sources and found just same set of parameters, as mentioned in doc, none of above. Displacement - if you operate with regular grids - can be tricky, because it is getting more and more popular photometric and depth scans, they may require huge datasets, which can be stored as level maps for optimizing and may require highly irregular grid structures.

[johguenther]

OSPRay uses the geometry normal of the (limit) surface for SubDs, currently no support for vertex normals.

index.texcoord, etc., is a proposal, not implemented yet.

[carsonbrownlee]

1. yes we need to update the ptex module.
2. hopefully our example module is helpful to some degree, though it only shows a small example with documentation- https://github.com/ospray/ospray/tree/master/modules/pluggableGeometryExample
3. (EDIT: looks like Johannes already commented on this) Embree itself supports face-varying interpolation for the subdiv input buffers. We haven't exposed that in OSPRay, but are you saying Embree's implementation itself is not sufficient?

[iqch]

-3. Yes, I said, that since OSPRay serves as Embree frontend -it is good to wait when it will support this feature. And some other like loop subdivision scheme. -2. I feel myself overhelmed a bit with poor documented source code now, sleazy cmake files, obsolete dependencies etc. Of course, it is typical situation, all my skills was achieved in same conditions - but I had some general line in developing which I permanently shoud leave to another siddhi :). Better have a documentation for this. -1. Yes, I seem it is an hour of work, if I understood that sourcecode right. I can promice to test it asap too

[iqch]

Ah, ok. I still cannot imagine, that such critical production feature may lack in modern renderer

[carsonbrownlee]

@iqch yes, OSPRay was originally focused on scientific visualization and we are still adding in features for studio rendering. We appreciate your comments and hope to add that soon, even if it may have taken us a while to get to it:)

[johguenther]

coming in the next release via 7d080b6eb30e8457c404f2eb388d32afddd63e01

[johguenther]

Face-varying attributes are now supported on Mesh and SubD via normal, color and texcoord data arrays (vs. the vertex.* variants which are vertex-varying).