THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 01:19, xxxxxxxx wrote:
I can't reproduce this. Putting for example the Spherify deformer from cinema4dsdk under a flattened Cube, I can still select its polygons when it's selected. When the polygon object is selected, its original state is shown for selection. It is not possible afaik to let the user select on the deformed object.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 08:37, xxxxxxxx wrote:
Maybe it's a hierarchy modifier thing (?). I see that Cinema 4D bones allow selection, even in a deformed state (Smart Bone option). But I donot understand what prevents my deformers from allowing selections. I must say that my bone plugin is *slightly* more complicated than the Spherify deformer (okay, even more complicated than C4D bones - over 2000 lines, not including the resources). Plus, it interacts with a set of plugin tags on the deformer.
I donot implement DetectHandle() and MoveHandle(), but GetDDescription(), GetDEnabling(), Read()/Write()/CopyTo(), CheckDirty(), and SetDParameter() are implemented. No idea where to even begin to look for a reason here.
If you want to look at the deformer plugin code (including resources), let me know. Too big to post here - and too sensitive as well. In the meantime, I will try some code commenting to see if that helps.
ETA: It should also be mentioned that it has been this way since it was first coded.
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 11:09, xxxxxxxx wrote:
Okay, so far I've done the following:
- Removed my plugin tags (which also carry animation tracks/seqs/keys) from the plugin bone.
- Commented out all of the plugin object's ObjectData and NodeData methods (that pretty much cripples the plugin, right?).
- Looked over my c4d_symbols.h and res/descriptions for all of the plugins.
- Disabled Exception handling (required for encryption).
The example that I'm testing is a 'prop' which has a single plugin bone. There is no change. As long as the plugin bone remains under the Polygon object, there is no way to select polygons.
***
There is no MFC or STL being used here.
This only really leaves several areas to check on my end:
There is a zlib.lib included in the project and the plugin bone depends upon it for compressing/storing the deformation weights. Don't see how this would have any effect - and there is none for a 'prop' as there are no deformations.
To be thorough here, I must state that this 'plugin' is a suite of C4D plugins which work in concert and are compile together into one plugin file (.cdl etc). There is a menu plugin with dialog, an object plugin (the one causing this grief), several tag plugins, and one unique plugin id for a subcontainer. Some of the tags and the unique subcontainer did not exist early on and the problem existed then.
The problem could be the result of some contention between them, but that would be hard to test as the object/tag plugins are not user-created (no menu option either) - they are created and setup for imported content. What I'm saying is that it would be rather difficult to isolate the plugin to see what happens as it doesn't do much in isolation and there are deep connections between this and the tag plugins.
That's my report for now. Will continue testing.
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 11:23, xxxxxxxx wrote:
Alright. In this code, there is one indicator that made a difference:
// Global Registrant Method for IPPBase plugin
//*---------------------------------------------------------------------------*
Bool RegisterIPPBase(void)
//*---------------------------------------------------------------------------*
{
return RegisterObjectPlugin(ID_IPPBASE, "iPP Base", OBJECT_HIERARCHYMODIFIER |OBJECT_MODIFIER|PLUGINFLAG_HIDE|PLUGINFLAG_HIDEPLUGINMENU, IPPBase::Alloc, "Oippbase", "Oippbase.tif", "Oippbase.tif", 0);
}
Guess which one? 
Taking that out, if I then disable the deformer, I can select polygons. With this in (which is necessary for a 'hierarchy modifier'), nothing happens.
This is the problem with the Spherify example in the SDK. There are significant differences between your garden-variety deformer as exemplified and your hierarchy modifier - obviously.
All of that testing and checking and it all boils down to a single flag. Now, if the built-in bones work the same but don't show this problem, then there is information that is required to know why. Maybe there is a Message() or some other thing that must be done or handled that I am not.
I leave it to you (or the developers) to reveal the cause.
ETA: Try this with the Spherify deformer. That is, add the OBJECT_HIERARCHYMODIFIER flag to the registration method. Same situation.
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 12:19, xxxxxxxx wrote:
Thanks for performing these tests and figuring out that OBJECT_HIERARCHYMODIFIER is the culprit. I have verified this with spherify.cpp and have asked the developers if there's a workaround available. (The built-in bones in 9.1 are not plugins, so they do not necessarily follow the same rules.)
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 12:30, xxxxxxxx wrote:
Hmm, actually I still can select the polygons after adding OBJECT_HIERARCHYMODIFIER. (I just hadn't entered the polygon mode when I thought that I had reproduced your findings.)
Could you be more precise how you do to make spherify.cpp reproduce the non-selectable polygons?
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 12:31, xxxxxxxx wrote:
And to be more precise as to what I did:
The result was that the undeformed cube was shown and its polygons were selectable.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 13:24, xxxxxxxx wrote:
I did nearly the same. For the cube, I set the segments to 16,16,16 and flattened (or made editable). Spherify enabled or disabled, no selection possible.
This is an unmodified version of the R9.102 cinema4Dsdk (apart from the one necessary modification for the test) compiled using VC++ 6.0, running in Cinema4D R9.102, Windows. All other plugins moved out.
Modules:
- BodyPaint3D
- Advanced Render
- MOCCA
- PyroCluster
- Thinking Particles
Normally, under these circumstances, I'd say that it is something wrong with my Cinema4D install or some setting. But this has been experienced by the beta-testers as well.
I did just note that if "Deformer Mode" is disabled ("Turn On/Off Deformers"), selection is possible on the undeformed polygon object even if the deformer itself is enabled.
Let's see what might be the real culprit then. You are certain that you are using the modified Spherify?
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 15:45, xxxxxxxx wrote:
The only change made to spherify.cpp:
From:
return RegisterObjectPlugin(ID_SPHERIFYOBJECT,name,OBJECT_MODIFIER,Spherify::Alloc,"Ospherifydeformer","spherify.tif","spherify_small.tif",0);
To:
return RegisterObjectPlugin(ID_SPHERIFYOBJECT,name,OBJECT_HIERARCHYMODIFIER|OBJECT_MODIFIER,Spherify::Alloc,"Ospherifydeformer","spherify.tif","spherify_small.tif",0);
Note that you need both flags for hierarchy modifiers. I have never been able to make them work without OBJECT_MODIFIER included.
This is "Win32 Release" Configuration compile. I just cleared the obj folder to get a clean compile again for more testing.
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 16:27, xxxxxxxx wrote:
What the heck?
Here's what I'm seeing with Spherify. If I do 16 segments on the Cube, doesn't work. If I do 8 segments, it works. To be more rigorous, anything above 12 (XYZ) doesn't work.
Any ideas?
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 16:52, xxxxxxxx wrote:
And to be even more rigorous, it appears that direct setting (click with Shift or Ctrl) works. It is only the Selection tools that seem to be having difficulty possibly with a certain number or density of polygons (will need more testing).
Both OpenGL and Software Shading were tested.
Looks suspiciously like a bug to me.
ETA: These revelations do not seem to hold for my own plugin hierarchy deformer though. Even a prop with only 1120 polygons won't select - not even Shift/Ctrl direct selection.
EETA: Although, a much simpler object, a Cone prop of only 90 polygons is selectable. Still unsure if this is quantity or polygon size or what (?).
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 18:03, xxxxxxxx wrote:
Get's even better.
Good = Selection tools work with my plugin
Bad = Selection tools unreliable most of the time with my plugin
Windows:
R8.2 Good (undeformed)
R8.5 Good (undeformed)
R9.1 Bad
R9.5 Good (deformed)
R9.6 Good (deformed)
MacOSX:
R9.1 Good (undeformed)
R9.5 Good (undeformed)
R9.6 Good (undeformed)
What's interesting here, again, is that this is not isolated to my R9.1 install. Several other beta testers have noted the same problem, and one of them is definitely on MacOSX.
Something odd about this.
Thanks,
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 19:37, xxxxxxxx wrote:
Hello Mikael,
How dumb. We never considered Viewport Configuration "Deformed Editing". Nothing to do with plugins or hierarchy modifiers (for the most part). Windows C4D R9.1 still does not work... if "Deformed Editing" is enabled. It does work if "Deformed Editing" is disabled. This would explain the difference between Windows and MacOS also - probably don't have this enabled in any of the versions there.
It is enough to drive you insane! 
We can stop going on about this I think.
Thank you very much,
Robert