-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document RawObj
in detail, Support higher order surfaces
#41
Comments
I quickly made a file in Wings3D – this is an all quad model. Feel free to use however you want. |
Hi @virtualritz! Thanks for using obj-rs and giving me a good idea! obj-rs have two types. One is I may have not tested all corner cases but AFAIK Maybe I can make some "n-gon Mesh to triangle Mesh" transformer as a separate crate but looks like it's not a trivial work. About higher order surfaces... yes you are right. They are part of the spec of Wavefront OBJ and obj-rs currently do not support it. I definitely need to implement it. |
TLDR; I would suggest to rename This is a new problem btw. If you had any library to read OBJs 10-20 years ago, it would always read the data as-is. I btw. predict that soon graphics cards will support subdivision surfaces. And then all the tools have to support quads and n-gons anyway. :)
|
At them moment I use the This is what I am using this for: https://github.com/virtualritz/rust-diffusion-limited-aggregation If |
RawObj
in detail, Support higher order surfaces
I've changed the title to make this issue more clear! Thanks for your comment :) |
Cool. If you support higher order surfaces, your lib will be outstanding. The only DCC apps that can read & write OBJs with NURBS or patches are Rhino3D and Maya, afaik. |
Oh, and Blender, apparently! |
5 years ago, I thought that hiding the low level But now, I think it would be better to show the RawObj type to the front, and to show the Obj types separately as a helper. Wavefront OBJ is too complex format and there are so many corner cases that can't be abstracted with simple How do you think? |
Many OBJ files are not made out of triangles and this is a feature. If I load an OBJ to send to an high end offline renderer, the last thing I want is probably triangles (so I also do not want the reader to convert the OBJ to triangles, on-the-fly).
To support this, a third array is needed that has one integer, listing the number of vertices per each face. So you would have:
This is an implicit part of the TODO 'support full OBJ/MTL spec'.
Which is actually a lot of work because then you also need to support higher order surfaces, e.g. NURBS, trim curves, bicubic patches etc. OBJ can store all of these and some apps (e.g. Maya) will also read and write such OBJs.
The text was updated successfully, but these errors were encountered: