Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/10/2008 at 11:20, xxxxxxxx wrote:
User Information: Cinema 4D Version: R10+ Platform: Windows ; Mac ; Mac OSX ; Language(s) : C++ ;
--------- Ok, I've been wrestling with this for a while now and have some observations and questions (for whatever Maxon programmer knows)...
...ok, given the above, but stated a different way:
...here are some additional observations regarding Normal Tags:
...I guess my questions revolve around that final point - are there any plans to 'fix' the Normal Tag, so that it updates itself? Or... I can imagine that there may be valid reasons for it to not be updated (relative to trying to divine the user's intentions, combined with interactions with a Phong Tag, etc). I'm just looking for "what" Maxon's position is on Normal Tags (?). I guess I should have stated this above somewhere, but my reason for asking about this subject is relative to my Riptide .obj file import/export plugin... .obj files (can) have Normals in them, so my plugin can read them to create the Normal Tag - I just need a better understanding of how/why they work the way they do, so I can better document that for my users. As it works now, it's great for 'special-case' files that have specific / intended Normals in it, but as soon as you 'do' anything to the mesh, the Tag becomes worse than useless (ie. a source of confusion). Thanks, Keith
On 21/10/2008 at 00:22, xxxxxxxx wrote:
As far as I can tell your observations about Phong and Normal tag seem to be right. The current behaviour of the Normal tag is rather intended or limited. If you want to have the Normal tag 'fixed' you should send this directly to MAXON.
cheers, Matthias
On 21/10/2008 at 01:04, xxxxxxxx wrote:
Thanks - I appreciate the answer - I just wanted to first make sure I understood how it worked and whether or not that was intended (or... at least acknowledged). I think the problem with 'fixing' the Normal Tag is probably why it works the way it does now... it would be difficult to divine the original intention behind how the normals in the Normal Tag were generated to start with. ie. they may have resulted from smoothing groups or some other mechanism in another app (I wrote a utility to generate 'smooth' normals across disconnected mesh objects that shared similar vertices, for example). I guess the only philisophical issue I have with the current implementation is that I don't think C4D (ie. any tools) ever updates the Tag at all... so if you add vertices/knife-cuts to the mesh, the Normal Tag now has too few Normals in it, leaving random/junk-memory values beyond the end of the array (at least I think the programmers should look into that, to verify whether that's happening or not). Anyway, I can at least document the (current) issues with Normal Tags for my users. Thanks again, Keith