st-interpolation

[iqch]

Does OSPRay itself use per-vertex interpolation for st, not per-point? It look like not - I render with Solaris asset (teapot from apple), only OSPRay shows it with artefacts over texture seams. Or it is introduced by hydra delegate?

[johguenther]

Do you mean face-varying texture coordinates? OSPRay does not yet support that (see https://github.com/ospray/ospray/issues/425).

[carsonbrownlee]

yes, this along with UDIMs are currently major missing features.

[iqch]

yes, this along with UDIMs are currently major missing features.

Hm, but which way OSPRay studio supports them?

[johguenther]

OSPRay does not have native support for UDIMs. Studio emulates UDIMs by packing all texture tiles in a single large texture, which is also planned for OSPRay for Hydra.

[iqch]

Oh! Noooooooo Ср, 15 сент. 2021 г. в 10:10, Johannes Günther @.***>:

OSPRay does not have native support for UDIMs. Studio emulates UDIMs by packing all texture tiles in a single large texture, which is also planned for OSPRay for Hydra.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ospray/hdospray/issues/11#issuecomment-919759315, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQD2CIL5K63726DA3JUGXTUCBBHLANCNFSM5D5AH6RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[iqch]

If it is possible to implement manually custom type of ospray primitives - why not to try to implement especially for hdospray such trivial thing as bi-cubic patch? Then hydra delegate will split subdivide mesh request to group of such patches and assign all primvars correctly. You may even not to use opensubdiv library, math laying around catmull-clark subdivisions are very simple and easily parallels. Areas around nontrivial vertices can be just subdivide till acceptable flatness amount and then interpolate with fan of bilinears. It can bring automatically UDIM resolving scheme too, just referring to one-piece from each patch (ok, it assumes, that st-coords are consistent, but they mostly are).

[carsonbrownlee]

UDIM has already been worked on and will be put in a future release. Subdivision is set to go through an overhaul to use opensubdiv. As for face-varying support, that will be added to the OSPRay renderer first and then supported in hdOSPRay, assuming that was the issue with the teapot texture seam.

[iqch]

1. If it will be implemented through combining to one big buffer - it will greatly impact performance.
2. Before Opensubdiv was released I've implemented such scheme (in 2006year) just based over original Jos Stam paper. All renderer anyway should split subdiv mesh to finite (bicubic for Catmull-Clark) patches, so why should you force another (overcomplicated, to be honest) code to do this trivial task?
3. face-varying data with ospray can be implemented by same way (and will be, I hope), but now Hydra delegate is one versatile way to get wide range of scenes and to test this feature and decide which benefits or waterstones it can bring. Sorry, but OSPRAYStudio looks not.
4. I seem, it is close H19 release, which can be based over latest USD version, which is incompatible already with current hdospray sources - so you will be overhelmed with adaptations, I fear. But latest USD builts embree delegate succesfully, possible it is not a real trouble.
5. And latest. Hydra itself now is a bottleneck for data exchange, despite it was invented as feature, which should solve this problem. Now once and most usable way to bring data to Hydra - it is use usd scene delegate, which is not extensible by plugins still, as I know, so you may be faced to necessity to develop scene delegate too. But why should you pass data through hydra then? To render them with renderman? What for do you make this project then? You can bring good scientific data rendering - but where to? Yes, usd itself is a great data organizing notation and technology, but do you really should exchange all data? You may introduce any schemes of data - you will not able to pass it to Hydra. I had such situation with tetrahedral meshes. Now I have my personal usd implementation which supports it, because it was embedded directly into sources. It looks no good. Do you have real vision of existence of this module?

[carsonbrownlee]

I would be very interested to hear what you are using it for, and your USD tet loader. We are in fact discussing using it more for sci vis focused applications and yes unfortunately you are then outside the realm of official hydra. However, that itself is not out of the ordinary for hydra given its limitations. Every studio seems to have their own data and shading systems built on USD/hydra. The issue you point out is that you then lose the ability to take that implementation and have it run across multiple applications. The solution is either to produce a representation of that data that does fit in a supported schema or create a new schema and attempt to have it standardized by other users.

[iqch]

I constantly research CG-production API's and techniques. I used USD directly as universal during scene format testing some simulation API - for example ARCSIM. I hate mess with OpenGL, OBJ, json etc - so I've found that USD/Hydra is great as least common multiple. For ARCSIM I develop testing gui based over usdviewq, now I'm playing with IPC libray, which simulates tetrahedral meshes too - in addition to rod, sheets and points. So I need robust library to exchange between DCC and offline simulation tool. Of course, when (or if) I'll implement it as internally executing module (Houdini solver for example) - it will be unnecessary - but Hydra can not only render images. It can perform simulation task too, and usd 21.08 has such features introduced already. More dedicated to RBD simulation, but it will drive further. here is my (awkward a bit) explanation about tetrahedral meshes implementation if you are interesting https://youtu.be/gRsmBefNE7c

[carsonbrownlee]

note: face varying support now in 0.10