Keith Young
04-11-2008, 09:31 PM
New Riptide update on my site (http://skinprops.com/)...
Release Notes:
v1.8
--------
This release primarily focuses on a major Ngon-handling update/re-write...
- Bug/Feature-Fix: Much improved Ngon handling
When I first implemented Ngon support in Riptide, it was a bit of a struggle finding the necessary information that Riptide needed - Ngons are implemented as a layer on top of existing triangles and quads in C4D and some of the developer documentation on the subject (and access routines for utilizing Ngons) was confusing, and/or not really suited to the task at hand. Anyway, I managed to glue enough code together to get Ngon support implemented a while back, but there were a few problems with that implementation...
1. When importing, I was using very simplistic triangulation (a fan of triangles) to form the underlying polygons (triangles/quads are still there - Ngons are layered on top of them). This approach meant that only 'Convex' Ngons would load correctly - 'Concave' Ngons (quite popular from apps like SketchUp) would end up with bad polygons. [ And, it was just plain ugly ;) ]
2. Either my import or my export (or both) would not maintain vertex ordering of the Ngon indices. The vertices themselves are never re-ordered, so this did not affect Poser morphs, but ZBrush (for example) also relies on the indices used by triangles and quads remaining the same and it's possible that those were changing in the triangulation process - of course ZBrush also doesn't handle Ngons anyway, so you already had to deal with those before-hand, but it may have been an issue with some other app(s).
3. Because of all the crazy (non-compliant) .obj file formatting Riptide supports, there was tons of "similar, but mostly duplicated" paths through the code, which left a lot of room for cut/paste errors on my part.
4. Related to the above, there were some other somewhat obscure problems found and fixed during the re-write.
...basically, I gutted the Import and Export Ngon handling code and started over from scratch. The new Import code uses Cinema4D's internal triangulation routines, resulting in quads/triangles and support for 'Concave' Ngons. This also included a fairly substantial re-structuring of my general polygon parsing code. With some additional effort, It now also maintains vertex-ordering for Ngons (yay).
There may or may not be (new) bugs in the code (none that I've found yet), but a side-benifit of the re-structuring is that it's now more consolidated (less room for typos) and easier to maintain.
[NOTE: Ngons with 'holes' in them are still not supported (no way that I know of to represent those in a .obj file)]
Finally, I also added support for "f v/ v/ v/" and fixed support for "f v// v// v//" formatted facet records (neither of which are compliant with the file format spec, but you'd be amazed at some of the stuff I've seen in .obj files). Riptide can currently parse the following facet record formats:
fo <plus any of the below> (really old format used 'fo' instead of 'f' for faces)
f v v v (<--- compliant, vertex-only)
f v/ v/ v/
f v// v// v//
f v/t v/t v/t (<--- compliant, vertex + texture vertex)
f v/t/ v/t/ v/t/
f v//n v//n v//n (<--- compliant, vertex + normal)
f v/t/n v/t/n v/t/n (<--- compliant, vertex + texture + normal)
...the v/t/n in the above examples are stand-ins for some 'vertex index' (an index into one of the tables), which can also be specified as negative offsets, which Riptide also supports, along with any embedded '\' line-continuation.
Anyway, "better Ngon support" was one of the few (only?) remaining reasons to force use of the C4D built-in .obj import/export - despite it's other issues, it handled Concave Ngons just fine. But enough geek-speak.. as usual, for more information or any questions, please visit the Riptide Support Forums - ( http://skinprops.com/ext/forum/forum_viewforum.php?9 (http://skinprops.com/ext/forum/forum_viewforum.php?9) ).
- Functionality: Holy Ngons
Speaking of Ngons with 'holes' in them (like a window cut out of a wall), since these can not be saved to a .obj file, a check is now run on the document before prompting for a filename. If any Ngons are found with holes in them on any mesh that is subject to export (visible and not restricted by an export mask tag), a new Yes/No dialog will pop up...
"At least one mesh object contains Ngons with 'holes'...
Click Yes to disable exporting Ngons and Continue.
Click No to Cancel."
...if you click Yes, the export process will continue, but the "Export Ngons" option will be disabled (it/they will be written out as individual triangles and/or quads instead of a 4+ sided Ngon). If you click No, the export is aborted.
To fix these Ngons for export, you can try knifing at least one new edge from an interior hole edge/vertex out to an exterior edge or vertex of the Ngon.
- Enhancement: Material Handling change
There was a recent inquiry about how materials are loaded/set when there's an existing material with the same name as one being loaded (when you merge an import into an existing scene). The short answer is that IF it's a 'standard' C4D material (ie. not a 'Shader' or Plugin material of some sort) and it has the same name, it would be updated with data read from the .mtl file. If it did not exist, or a non-standard material with that name existed, a new material
would be created with the .mtl file data.
If you already had a bunch of materials in the scene converted to Vray materials (whatever format that is), or some other plugin material, this could leave you with a lot of work to clean up all the material references.
With this release, the functionality has changed as follows:
* if no material exists in the scene with the desired name, a new one is created.
* if a 'standard' C4D material exists in the scene with the desired name, it will be updated.
* if any non-standard (or plugin) material exists in the scene with the desired name, it will be used, but not altered.
...this change means that shaders (like Nukei, Banji, Danel, Fog, Cheen, etc) as well as any plugin materials (like Vray) would be used if they were already set up in the scene. I don't have Vray and hadn't done a lot of testing with this change, so let me know if there's any problems.
[ NOTE: As always, only standard materials can be 'exported' ].
- Bug/Functionality: Bump Map record change in .mtl files
As noted in the previous release, the Wavefront .mtl file-spec indicates that the record for a Bump Map file is 'bump'. Some applications use 'map_bump' and some (including all previous versions of Riptide) use 'map_Bump'.
One design goal I've tried to follow with Riptide is:
* on import, parse/support as much odd-ball formatting as possible for any supported features/records
* on export, don't create any odd-ball formatting or non-compliant records
...with this in mind, I have decided to take the high-road and change Riptide to use the proper 'bump' record on export, to be compliant with the file-spec. Of course Riptide will still accept any of the 3 when importing, so this only affects files exported by Riptide.
Release Notes:
v1.8
--------
This release primarily focuses on a major Ngon-handling update/re-write...
- Bug/Feature-Fix: Much improved Ngon handling
When I first implemented Ngon support in Riptide, it was a bit of a struggle finding the necessary information that Riptide needed - Ngons are implemented as a layer on top of existing triangles and quads in C4D and some of the developer documentation on the subject (and access routines for utilizing Ngons) was confusing, and/or not really suited to the task at hand. Anyway, I managed to glue enough code together to get Ngon support implemented a while back, but there were a few problems with that implementation...
1. When importing, I was using very simplistic triangulation (a fan of triangles) to form the underlying polygons (triangles/quads are still there - Ngons are layered on top of them). This approach meant that only 'Convex' Ngons would load correctly - 'Concave' Ngons (quite popular from apps like SketchUp) would end up with bad polygons. [ And, it was just plain ugly ;) ]
2. Either my import or my export (or both) would not maintain vertex ordering of the Ngon indices. The vertices themselves are never re-ordered, so this did not affect Poser morphs, but ZBrush (for example) also relies on the indices used by triangles and quads remaining the same and it's possible that those were changing in the triangulation process - of course ZBrush also doesn't handle Ngons anyway, so you already had to deal with those before-hand, but it may have been an issue with some other app(s).
3. Because of all the crazy (non-compliant) .obj file formatting Riptide supports, there was tons of "similar, but mostly duplicated" paths through the code, which left a lot of room for cut/paste errors on my part.
4. Related to the above, there were some other somewhat obscure problems found and fixed during the re-write.
...basically, I gutted the Import and Export Ngon handling code and started over from scratch. The new Import code uses Cinema4D's internal triangulation routines, resulting in quads/triangles and support for 'Concave' Ngons. This also included a fairly substantial re-structuring of my general polygon parsing code. With some additional effort, It now also maintains vertex-ordering for Ngons (yay).
There may or may not be (new) bugs in the code (none that I've found yet), but a side-benifit of the re-structuring is that it's now more consolidated (less room for typos) and easier to maintain.
[NOTE: Ngons with 'holes' in them are still not supported (no way that I know of to represent those in a .obj file)]
Finally, I also added support for "f v/ v/ v/" and fixed support for "f v// v// v//" formatted facet records (neither of which are compliant with the file format spec, but you'd be amazed at some of the stuff I've seen in .obj files). Riptide can currently parse the following facet record formats:
fo <plus any of the below> (really old format used 'fo' instead of 'f' for faces)
f v v v (<--- compliant, vertex-only)
f v/ v/ v/
f v// v// v//
f v/t v/t v/t (<--- compliant, vertex + texture vertex)
f v/t/ v/t/ v/t/
f v//n v//n v//n (<--- compliant, vertex + normal)
f v/t/n v/t/n v/t/n (<--- compliant, vertex + texture + normal)
...the v/t/n in the above examples are stand-ins for some 'vertex index' (an index into one of the tables), which can also be specified as negative offsets, which Riptide also supports, along with any embedded '\' line-continuation.
Anyway, "better Ngon support" was one of the few (only?) remaining reasons to force use of the C4D built-in .obj import/export - despite it's other issues, it handled Concave Ngons just fine. But enough geek-speak.. as usual, for more information or any questions, please visit the Riptide Support Forums - ( http://skinprops.com/ext/forum/forum_viewforum.php?9 (http://skinprops.com/ext/forum/forum_viewforum.php?9) ).
- Functionality: Holy Ngons
Speaking of Ngons with 'holes' in them (like a window cut out of a wall), since these can not be saved to a .obj file, a check is now run on the document before prompting for a filename. If any Ngons are found with holes in them on any mesh that is subject to export (visible and not restricted by an export mask tag), a new Yes/No dialog will pop up...
"At least one mesh object contains Ngons with 'holes'...
Click Yes to disable exporting Ngons and Continue.
Click No to Cancel."
...if you click Yes, the export process will continue, but the "Export Ngons" option will be disabled (it/they will be written out as individual triangles and/or quads instead of a 4+ sided Ngon). If you click No, the export is aborted.
To fix these Ngons for export, you can try knifing at least one new edge from an interior hole edge/vertex out to an exterior edge or vertex of the Ngon.
- Enhancement: Material Handling change
There was a recent inquiry about how materials are loaded/set when there's an existing material with the same name as one being loaded (when you merge an import into an existing scene). The short answer is that IF it's a 'standard' C4D material (ie. not a 'Shader' or Plugin material of some sort) and it has the same name, it would be updated with data read from the .mtl file. If it did not exist, or a non-standard material with that name existed, a new material
would be created with the .mtl file data.
If you already had a bunch of materials in the scene converted to Vray materials (whatever format that is), or some other plugin material, this could leave you with a lot of work to clean up all the material references.
With this release, the functionality has changed as follows:
* if no material exists in the scene with the desired name, a new one is created.
* if a 'standard' C4D material exists in the scene with the desired name, it will be updated.
* if any non-standard (or plugin) material exists in the scene with the desired name, it will be used, but not altered.
...this change means that shaders (like Nukei, Banji, Danel, Fog, Cheen, etc) as well as any plugin materials (like Vray) would be used if they were already set up in the scene. I don't have Vray and hadn't done a lot of testing with this change, so let me know if there's any problems.
[ NOTE: As always, only standard materials can be 'exported' ].
- Bug/Functionality: Bump Map record change in .mtl files
As noted in the previous release, the Wavefront .mtl file-spec indicates that the record for a Bump Map file is 'bump'. Some applications use 'map_bump' and some (including all previous versions of Riptide) use 'map_Bump'.
One design goal I've tried to follow with Riptide is:
* on import, parse/support as much odd-ball formatting as possible for any supported features/records
* on export, don't create any odd-ball formatting or non-compliant records
...with this in mind, I have decided to take the high-road and change Riptide to use the proper 'bump' record on export, to be compliant with the file-spec. Of course Riptide will still accept any of the 3 when importing, so this only affects files exported by Riptide.