Sculpt Tag changes don't change dirty flags. Why?
-
On 03/08/2017 at 09:43, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R17
Platform: Windows ;
Language(s) : C++ ;---------
Hi C4D,We have Interactive Preview Render (IPR) mode which relies on dirty flags such as GetHDirty() and GetDirty() that we check for Document. If changes then we look into the hierarchy of objects. If changed (or if the order is changed) then we collect object data and send to IPR. All of this is super fast.
But! If we attach the Sculpt Tag to some object. Then it doesn't change the values of GetHDirty() or GetDirty(). I have tested all available flags of these functions, document, objects itself, even the tag flags were tested. User changes the object with attached Sculpt Tag in Editor, but dirty flags doesn't change.
How can we automatically detect such changes? We just don't want to enter the level of data content and compare all the polygons one by one. Need flags that work well for other cases.
Best regards,
Aaron -
On 07/08/2017 at 04:49, xxxxxxxx wrote:
Hi Aaron,
unfortunately there is no dirty flag or anything equivalent in order to detect sculpting changes. Sorry, regarding to development this was a deliberate decision for performance.
-
On 13/08/2017 at 05:18, xxxxxxxx wrote:
Hi Andreas, I see. Tested everything. However, let's think about a workaround.
An idea:- Collect links to objects with Sculpt Tags.
- Detect if user is working with some Sculpt Tool like knife
- Detect selected object.
- Force updates on selected/active objects with Sculpt Tags
Question: is it possible to detect #2 item?
-
On 13/08/2017 at 08:17, xxxxxxxx wrote:
You can catch it using EVMSG_TOOLCHANGED. Then you just have to get the active doc and get the active tool.
I didn't try but maybe EVMSG_CHANGE will success for detect change.
-
On 14/08/2017 at 08:53, xxxxxxxx wrote:
@Aaron: Well, maybe you could (as gr4ph0s already suggested), but I'm afraid you will bog down sculpting performance by doing so. In the end, if I understand correctly, you are suggesting to force those updates, that were avoided in the sculpting pipeline to keep the performance high. So, if you decide to go that route, I recommend to be careful and thorough testing, especially of performance impacts.
-
On 14/08/2017 at 11:56, xxxxxxxx wrote:
Andreas, sure you are right. It depends on the size of the object under the sculpt, and how far we can go with optimizations and what can go to background threads. One potential idea is to allow this to work automatically with all this complex coding construction if detect small polycounts. If detect too large polycounts which may slowdown the main activity then show a message attracting to click a button after huge changes.
E.g. is there any chance today to read object polygons in a background thead asynchronously? Potentially inside some critical section. Currently it's possible to do some multi-threaded process with scene launched in Main thread but we need to block it until this multi-threaded process finish the job.