THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/08/2005 at 17:30, xxxxxxxx wrote:
Cinema 4D Version: 8.2+
Platform: Windows ; Mac ;
Language(s) : C++ ;
I would like know the previous object position to calculate the vector from current position to previous.
Thanks for the help
On 06/08/2005 at 20:42, xxxxxxxx wrote:
You'd need to store the object's position always and use that value (before updating it) and the current position to determine delta position change. Cinema 4D doesn't track previous object states - except in the Undo stack and Animation keys.
ETA: If you need two specific positions, you might need to use buttons for the user to mark start and end positions, performing the calculation on marking the end position.
On 06/08/2005 at 21:02, xxxxxxxx wrote:
thanks for reply. I just would know if there a previous cache about global matrix.
I've just use an array to save it, the only dubt is about allocation and freeing of memory. Just got some probs on it... and i'll like to make a clean code to prevent bugs
On 06/08/2005 at 21:57, xxxxxxxx wrote:
No previous cache for the global matrix as far as I know.
You could store the matrix in the object's BaseContainer (whenever voff changes from the matrix already stored). As noted previously (see Saving data indocument, although COFFEE it is still relevant), use a subcontainer (with unique plugin ID) to avoid ID conflicts. Store the matrix (and any other data) within your subcontainer using SetMatrix()/GetMatrix(). Your plugin will then need to monitor object position changes and read/write the subcontainer value to do its thing.
ETA: this subcontainer and data within it are automatically saved and reloaded with the .c4d scene file.
On 06/08/2005 at 22:40, xxxxxxxx wrote:
but i dont know the number objects (in nota plug) so the dimension of array. Can i always store these matrix in basecontainer?
On 07/08/2005 at 00:09, xxxxxxxx wrote:
If you store the matrix of each object in the BaseContainer of that object, you'll never need an array of matrices - that was the point. You'll just need to traverse the document's hierarchy (or the children of your plugin object, if that is the case), which is not too slow for this process, to get to all of the objects and process the matrices. The other good thing is that you can always check for the existence of your unique subcontainer and add it if it doesn't exist in any newly added objects. Deleted objects automatically take the subcontainer with them.
The advantages of using Cinema 4D's internal container structure are that you never need to allocate/free memory or implement read/write/copyto. It is all done automatically. The disadvantage to BaseContainers is that they have no array storage capabilities. I've used Dynamic Descriptions using GetDDescription() for Attributes to accumulate lists of, say, morphs requiring that blocks of IDs be set aside for maximum counts. But there is no analogous way to do this automatically using BaseContainers (though it can be done to some extent).
On 07/08/2005 at 01:02, xxxxxxxx wrote:
You should not really start inserting container IDs into an objects container. There is only one place this is allowed, that is the document settings as MAXON will ensure the IDs are ok if you use a unique plugin ID, but this is the only place that it is valid.
If you add your own data into an object then who is to say you have used a unique ID? A plugin developer or even MAXON are free to use any IDs they want within an objects own container, this applies to materials, tags etc.
It might be unlikely you overlap, but you can not be sure.
A basecontainer is also not ideal for data use, its ok for settings but a basecontainer can be slow to access. Its just a list so each ID must be search for.
If you want to know the previous objects matirx then just store it in your own local data. Create an array with a baselink (or pointer provided you never access it without checking its valid) and just update the array as needed (adding, removing objects).
On 07/08/2005 at 02:24, xxxxxxxx wrote:
I would have never expected that, but then I guess that arbitrary values for BaseContainer IDs in an object could be used without consideration of Plugin IDs. Just extrapolating from that post. Thanks for the correction!
In that case, I don't agree with an array to some degree.
In cases of varying numbers of objects, it might be better to use a linked list, unless you don't expect to allocate/free/allocate the array often (which obviously cannot be guaranteed if the addition/removal of objects is completely user-based). With arrays, you'll either need to copy the valid elements to the newly allocated array or go through the process of data reconstruction for every allocation. At least with linked lists you can simply append/insert/remove elements. Of course, you get more possible memory fragmentation this way. Weigh your options.
On 07/08/2005 at 03:12, xxxxxxxx wrote:
It depends on access, lists are slow in all cases, but inserting/removing data isn't much of a hit if you do your memory management right and don't keep allocating nodes on the fly. Inserting/Removing data in array depends on its size and the data you move, but access is always fast.
If you are not inserting/removing objects often or at times that are not crucial to speed then an array is better, especially if you don't expect to be shifting much data round (i.e. hundreds/thousands of elements, not millions).
There are also smarter ways to use an array that is fast on insert/remove and still fast for data access these come close to lists for insert/remove and come close to array access times or the same
On 07/08/2005 at 14:58, xxxxxxxx wrote:
Yes, lists are slow, but it's not just the numbers of list items, but the size of the list items as well. I deal with lists that are hundreds/thousands of items, but each item contains 10's of KB of data. This means tens (sometimes even hundreds) of MBs for a array which could potentially (and probably frequently) have difficulties when praying for those large chunks of memory to be available for every allocation and reallocation. And the item numbers vary widely, so guessing maximums will assuredly lead to limitations and/or memory waste. Additionally, arrays aren't very condusive to constructing hierarchies.
Again, all depends on circumstances. For storing a baselink and matrix, arrays are probably more than sufficient, yes.
Not to go off topic, it would be great if memory management wasn't solely placed into the hands of the developers - not like there isn't much else to do when developing complex software!
On 07/08/2005 at 22:43, xxxxxxxx wrote:
CINEMA does have its own memory management and its pretty quick. Calls to GeAlloc use an internal memory pool and you can always use the MemoryPool class.
If you have specific memory requirements though (as with anything) you can not beat writing your own for the use you need, general class are not always as efficient as a dedicated implementation for a specific use.
On 07/08/2005 at 23:26, xxxxxxxx wrote:
Yes, i read it in Sdk and i use memory api.
Anyway, i got my good result when adding a new feature on my plug.