Add support for NURBS surfaces in Wavefront .OBJ files. #117371
No reviewers
Howard Trickey
Aras Pranckevicius
Jesse Yurkovich
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#117371
Loading…
Reference in New Issue
No description provided.
Delete Branch "Germain-Le-Chapelain/blender:fixattemptcurveobjexport"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Signed-off-by: Germain Le Chapelain germain.lechapelain@lanvaux.fr
This is to address the sample data kindly provided in https://devtalk.blender.org/t/nurbs-import-export/17581/14?u=germain_le_chapelain
(Calling for feedback if possible, I don't really know what I am doing yet :/ )
Created #117430 to describe the problem this solves. I couldn't find it reported
I am now looking at those tests and crashes without that code changes. Sorry I would have been out-of-order through and through on this.
I will post back my findings.,
Fix for 3D curves.. Why do we segment them ?to WIP: Fix for 3D curves.. Why do we segment them ?WIP: Fix for 3D curves.. Why do we segment them ?to Fix for 3D curves.. Why do we segment them ?There are 3 types of curves in Blender. Poly, Bézier and NURBS. The OBJ exporter currently only has code to export Poly and NURBS curves, and for that reason Bézier curves are exported as a mesh.
To be able to export Bézier curves, you'd need to check an OBJ wavefront specification, figure out what the syntax is for them and then implement the logic to write them out correctly. And then find an application that supports importing Bézier curves from OBJ and check that it works correctly.
If you change the code, it is normal for some tests to fail. The test works by comparing the exported OBJ against a reference file, and this will need to be updated, once it has been verified that the output is correct.
Fix for 3D curves.. Why do we segment them ?to WIP: Fix for 3D curves.. Why do we segment them ?Pretty sure the logic is not there, as there is no
cstype bezierin the code, onlycstype bspline.https://paulbourke.net/dataformats/obj/
Yeah I'm not sure if the code as-is actually solves your problem properly. If you want to implement support for exporting Bezier curves as actual curves, then sure that could be implemented. I don't know why in the original code it was not implemented. My guess is that perhaps 1) the original Python OBJ export code did not have it implemented for some reason, and/or 2) generally other applications do not support Bezier curve types in OBJ files anyway.
Hello !
I remembered I had got my hands on the document with the formulas (included. I forgot where I saved it from.
It should be easily retrievable.)
I updated the PR, Basically it is surfaces that I am really after,
I'll keep cracking
So far to me it's not clear what are you after, actually. Are you after being able export curves as Beziers? Or after exporting surfaces/meshes as some sort of spline (e.g. NURBS) representation?
In either case, it would help to: 1) clarify which other software out there actually understands these obj format varieties, 2) implement code to do that, and check whether new curve/mesh type can export form blender and import into said software, and export form said software and import into blender correctly.
To any useful end: I am dropping here the file I am trying to load in:
I will update w/ what I have shortly.
Basically I don't understand jack-💩 to how those surface control-points are laid-out.
(I sure I am glad I had the document w/ them diagrams in it :D)
fa717d8071to353a14096bWIP: Fix for 3D curves.. Why do we segment them ?to Fix for 3D curves.. Why do we segment them ?Fix for 3D curves.. Why do we segment them ?to WIP: Fix for 3D curves.. Why do we segment them ?WIP: Fix for 3D curves.. Why do we segment them ?to WIP: Add support for importing NURBS & BSpline surfaces from Wavefront .OBJ files.WIP: Add support for importing NURBS & BSpline surfaces from Wavefront .OBJ files.to WIP: Add support for NURBS surfaces in Wavefront .OBJ files.Wouaïa ! So this is where the PR stands: When I try to import
(The file above)
I end-up w/ a model with holes in it. I am suspecting it has to do with these cyclic flag
b8d4d26c41to7327a3f9427327a3f942to48a220709248a2207092to42e8c81d1742e8c81d17tob376773279So my surfaces aren't precisely exporting as they import: ^^
That could be (one of) the problems.
[-] One typo for sure where writing control point for the surface in the wrong order: Wavefront .OBJ file specification § `Surface vertex data', paragraph `Control points'. [?] They other one I have no clue: It's about the order/degree & `resolution' (# of control points ? So I made it to that. rather than try guessing which was what I was doing before. But the original code just plain set it to 12 :|. Perhaps was that the issue with the 2D curve (which should be working) was in that post from the forum thread I had cited initially in this PR.)Closing for now,
I'll reopen when there be sthing to look-at
For reference this is what I am sitting on on this branch:
WIP: Add support for NURBS surfaces in Wavefront .OBJ files.to Add support for NURBS surfaces in Wavefront .OBJ files.This is how it looks now:
Not shabby but not what's in the original software, still. I reloaded the exported data in it and the rendering checks out.
Could it be that Blender renders/evaluate NURBS differently than Ayam ? More likely I might be doing something wrong with the weight:
(One change is from bspline to rational B-splines.
Looks like what would happen if you mixed up the weights on odd/even columns, possibly as a result of incorrectly compensating for 'cyclic'.
Thank you so much, let me have a look
When I wrote nothing is changed, it was not true.
I forgot but commit
7423a6c5fbchange the order of operationHowever I believe it is a bug in the original importer: I.e.: Cycling end point after importing the model shows something different than when it is initially loaded (It doesn't look correct the 1st load in. I think this is what is complained about in the forum post I site at the very beginning ?)
I can dig further/file a bug.
I will work off from NURBS Sphere on both software, also someone kindly pointed at the `screw modifier' in the chat
So that cycli..sm.. It should only matter upon export, not importing ?
I.e. this isn't represented in the .OBJ file. It merely has a CP index pointing back to the 1st one in the sequence ?
(Though then my change should output and re-read nicely a NURB Sphere from Blender.
Spoiler: it does not. I did get that export part wrong. But again that isn't the pb in the picture above)
I'm putting the two file exports I get from each software package. (They don't have the same # of CP.
But I think there are different ways to represent a sphere w/ NURBS so I don't want to get hooked-up on that. )
I'll look and fix my export.
Also, the issue I was mentioning in the forum post seems to be about these endpoints not being ticked at all.
Once they are checked, the model appear like it was out of Rhino. I am not saying this is right, however it does look like it does in Rhino when loaded-in that other Ayam software package:
Now w/ all that and the specs up-above there should be everything that's needed to crack this conundrum :D
I would love to get my hands on Rhino too but got no reason to question Ayam so far.
Cheers again for the look-at & the exchange!
I haven't used NURBS for anything serious and can't tell you how common or uncommon specific settings are.
I know that in the idTech series of game engines, "curve patches" behave like Blender NURBS with both "Bezier" checkboxes ticked, both "Endpoints" ticked, no "Cyclic" option available (instead the last row/column is a duplicate of the first one) and 3x3 "Order" (which limits them to odd number of points along both axes).
The weight issue seems really easy to debug: just check the values at specific points once imported. On a perfect circle/cylinder/lathe/sphere, the corner points would have weight 0.707. If this isn't the case, something is going wrong during import.
A NURBS sphere primitive in Blender has 40 points. 45 if you turn off cyclic and append first row as last. Consistent with this, Ayam output obj has 45 points. So if that's your reference (why?), you should be adding a duplicate row on export and possibly skipping one on import.
Your Blender output obj has 40 points, yet also has numbers from 1 to 50 in the surf definition. This seems incorrect, but I don't know enough about obj syntax to say for sure. In Ayam's case there are 45 indices, matching the number of points. It's possible (I'm just guessing) that you can re-use these indices, which would allow you to do cyclic surfaces without duplicating rows. Then again, even if this is allowed by the spec, it's also possible that other software (e.g. Ayam) won't be able to open the file afterwards.
Checkout
From your project repository, check out a new branch and test the changes.