THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/01/2003 at 13:12, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 8.012
Platform: Windows ;
Language(s) : C++ ;
---------
What´s the difference between GeneratePrimitive and BaseObject::Alloc(Oxxx)? Any speed issues?
Thanks
Samir
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/01/2003 at 13:29, xxxxxxxx wrote:
It is just a convenience function, there should be no difference in speed really. Do you know where the bottle neck is in your plugin? try running some timing tests or a profiler to find out which bits need a boost. Looking for faster commands isn't likely to help much 
is this the same project that had the rotations issue? just wondering 
sure you are using the caching system in c4d correctly? I ask too many questions 
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/01/2003 at 13:38, xxxxxxxx wrote:
It is just a convenience function, there should be no difference in speed really. Do you know where the bottle neck is in your plugin? try running some timing tests or a profiler to find out which bits need a boost. Looking for faster commands isn't likely to help much
-----------------------------
Well I couldn´t encounter anything while debugging but maybe I have overseen anything? (that´s why I am now checking for faster commands. I have tidied up my code today, some things really were baaaaad. But now I can´t see anything that could really slow my code down "that" much.) But you are right, some simple speed tests is a good idea. See how I can do it. You know, new to all this.
-----------------------------
is this the same project that had the rotations issue? just wondering
.....................................
yep... *ashamed*
------------------------------
sure you are using the caching system in c4d correctly? I ask too many questions
------------------------------
No! questions are good. As you maybe know I am not working too long with C++ for C4D too long (3 months?) and I still do miss a lot of things and am not as fit as I want to be. Any help or advice is usefull and helpful for me and is highly appreciated.
Thanks
Samir
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/01/2003 at 13:54, xxxxxxxx wrote:
ok
First off, never ever ever in a million years (you may not have or changed now), use GetActive anything the only time you can safely use that is in a dialog, any other function (in a tag or object) will always pass to you the document it is called for, e.g. HierarchyHelp is your friend use GetDocument() and always use the thread to do TestBreak anywhere that does lots of loops or long calculations, but don't call it too often or it'll slow everything down, also, always pass the thread into any function wanting it.
Second, this bit is VERY important for the cache system:
Bool dirty = op->CheckCache(hh) || op->IsDirty(DIRTY_DATA);
if (!dirty) return op->GetCache(hh);
Checking that you don't need to rebuild your object it vital, otherwise it'll rebuild every single time the user moves around, the camera and object. The only time you should ever rebuild is when the cache is dirty, doesn't exist, or your object needs to change. The RoundedTube example is a good one, the Atom is good if you are an INPUT generator (which you are not are you?) think yours is a plain one (like RoundedTube).
That's all I can think of from the bits I saw and top of my head
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/01/2003 at 16:44, xxxxxxxx wrote:
First off, never ever ever in a million years (you may not have or changed now), use GetActive anything
----------------------------------------------
upps. am sometimes using it and sometimes from the hierarchy help. Ok, will change that.
----------------------------------------------
and always use the thread to do TestBreak anywhere that does lots of loops or long calculations, but don't call it too often or it'll slow everything down, also, always pass the thread into any function wanting it.
----------------------------------------------
yes, I am already doing that. thanks for confirmation though.
----------------------------------------------
Second, this bit is VERY important for the cache system:
Bool dirty = op->CheckCache(hh) || op->IsDirty(DIRTY_DATA);
if (!dirty) return op->GetCache(hh);
The RoundedTube example is a good one, the Atom is good if you are an INPUT generator (which you are not are you?) think yours is a plain one (like RoundedTube).
----------------------------------------------
Ah! yeah, it´s a plain one but I always thought that´s only used when using Input objects so I didn´t use it! Well, never had a look at the rounded tube example. Will have one now. Unfortunately am not at home this weekend so will check it out on monday. But I guess that´s a good advice! Very good. Thanks very much Dave! (how much do I owe you know? It sums up to a lot now I guess
----------------------------------------------
That's all I can think of from the bits I saw and top of my head
----------------------------------------------
Just great! Am thankful.
Thx!
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 03:37, xxxxxxxx wrote:
ill add a tip for generators
if you are building your own geometry , when you first alloc your object , build it with what you can reasonablly expect to be its absolute maximum size.if you have then built a recursive function that keeps adding stuff to your original mesh , ask each time before you add new part , if the memory is still big enough to hold it.if it is , just add it.
This will be an order of magnitude faster than using the deadly "resizeobject" !!!!
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 06:34, xxxxxxxx wrote:
It is also a dangerous game to play with memory if you start eating up users memory with the "maximum" size you may ever need, they could have been using that for rendering! and not to forget, you don't know when your object is getting cloned, that can start to be LOTS of unwanted, unused memory hanging about, that is worse than loosing a little speed! if you are having to do that to gain some speed ups, you need to ask yourself why, and if you've gone wrong somewhere
You should never really be using resize in a generator anyway 
if your creating the sort of object that changes size you would be better creating it each time, resize should only -ever- be used if you really really have to use it!
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 06:58, xxxxxxxx wrote:
It is also a dangerous game to play with memory
how can it be dangerous?
if you build an object , its not gonna get cloned untill you finish building it and pass it to the cash.
you only need use resize when your finished, to correct the final size.
for example.
your making some grass out of polys.
you know you have 1000 grass strands , but you cant say at the start how many points and olys a bit of grass is gonna use.
so you go through adding and building grass poly sets.
you can do this 3 ways
1:you can create each blad eof grass as a seperate object and group then under a null.and maybe join them together at the end.this would take ages and be a wosst possible case build.
2.creat an empty object.and each time you want to add the polys and points for a new blade of grass , you build the blade and add it to the main object by means of resizeobject , cos there is no other way to do this.this would also take ages , cos resize object is a killer.
3. you use my way and alloc a fair maximum ram first.then you add the new points and polys as you go.you check one time at the end and correct the ram size.This may be between 2 and 1000 times faster than doing any of the other methods and requires no more memory than any of the other method.You dont have to worry about using up ram that other things could have needed , cos the final ram size is pretty much the same no matter how you do it.
i have dont this many times its safe as house.
so the word danger does not apply here
and why on earth do you say you should never use resize in a generator.
where else would you use it?
you can use it anywhere you like , even in a deformer.(also safe as houses)
cheers
Paul
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 07:01, xxxxxxxx wrote:
cache not cash
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 08:23, xxxxxxxx wrote:
Creating objects in that way is not very efficient your main object (plugin object) can be cloned for many reasons, including just rendering, what I was meaning was that you will end up using resources that you don't need, that takes vital memory away from other areas that may or may not need it. It isn't dangerous as in it'll explode the computer, but in that you should not get into bad habits, and that is one!_<_o:_<_o:p_>_o:p>
When creating a generator object, it is similar to creating a shader, it needs to be as efficient and fast as possible, resize is not that fast, it will have to duplicate the memory allocation then refill it, it is useful, but in situations where you need speed and efficiency, it isn't that good to rely on it, and just creating one monster object is also not wis_<_o:_<_o:p_>_
If you really can't work out how many points/polys your object is going to need, then you need to look at how your system works, or build the object up from smaller ones where you do know the sizes, but not too many (like one object per blade of grass!) otherwise you again run into efficiency issues. If you really have no way to know the overall size, then maybe it is a difficult choice of memory and speed, guess it depends how much waste is le_<_o:_<_o:p_>_.
... an_<_o:_<_o:p_>_ur answers
1> why j_<_o:_<_o:p_>_m? you don't have to!
2> NO NEVER! you should never repeat using resize over and over, it will be very very slow! resize itself is not a killer (Windows support memory resizing, don't know about Mac, but any memory resize is not that efficient, n_<_o:_<_o:p_>_llocation for that matter!).
3> is like a memorypool, if the waste is minor it is no problem, but if you really have no way to know how big your object will be, then the size is a guess? and if not a complete guess, you must know the final size? or I guess you do know approximately the final size, so allocate on the big side? hope that is_<_o:_<_o:p_>_o) or do you have shares in RAM
Yes it is "safe", you won't crash, you can do anything you like to your polygon _<_o:_<_o:p_>_provided it is returned as a valid object.
There are many ways to create objects, the overall best way is to know just how big it will need to be! in the case of the project Samir is working on, last time I saw anything it was creating single objects in a hierarchy, that is fine, just like the Atom _<_o:_<_o:p_>_, no join, no resize, no waste, nice and fast
If it works, use it, but watch out that it doesn't bite back later two things should be (tried) to keep in mind when programming anything, especially in something as CPU hungry as a 3d app, speed, efficiency, and can you do it faster! always the last one, time test every part, know how long it takes, why it takes that long, and can it be faster and more efficient. Takes time, but the end product is worth it! maybe I'm just a bit old school, I still remember spending hours just tweaking a few lines of 68000 assembler back in the good old days just to get that extra bit of speed
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 08:35, xxxxxxxx wrote:
1> why join them? you don't have to!
but if you can , do it
why?
perpare time before render.
100,000 objects with 1 poly = go have a cup of tea and eat someting
1 object with 100,000 polys = not enough time to fart
cheers
Paul
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 09:11, xxxxxxxx wrote:
If you're going to preallocate memory, don't forget the trusty old amortized constant double-after-full allocation scheme. I.e. each time you run out of points or polygons you add as many as you have, doubling the number. (It wasn't clear if you already do it this way. Disregard this if you do.)
See this random link for more information: http://c2.com/cgi/wiki?DoubleAfterFull
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 09:28, xxxxxxxx wrote:
ill print that and hang it on the wall .
for it will help me in those moments of doubt.
much like Mary Poppins in her trusty old film , ill sing the words
"trusty old amortized constant exponential allocation scheme","trusty old amortized constant exponential allocation scheme"
until i feel better
I hadnt called it that , but its not far off what ive been doing.
thanks for that one
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 10:30, xxxxxxxx wrote:
That is the largest pile of dog stuff I ever read! that is seriously bad practice unless you really really need dynamic array allocations! there are better ways! really, there are!! use your brain and memory, not the computers! in the case of object allocations, I stick by my point, allocate what you need, no more, you should -know- how big that is! really, you should!
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 11:30, xxxxxxxx wrote:
Oh, just one final (I think) point, the JOIN issue, I don't know what the official word is, but I can show you scenes where JOIN'd objects are actually slow in prepare/render than their unjoined versions! AFAIK, during prepare, the polygons are converted to RayPolygon's per object, during this conversion, the validity of the polygon is checked, if it is invalid it is split into tris or ignored depending on the "problem" with the polygon. This is what takes the time, cloning the scene, converting the polygons to raypolygons. I can't say I see why the number of objects should matter, other than, small memory allocations can be slower (sometimes) then one large one, but unless you are repeating this 100,000 like times, the difference is minor, with it going one way or the other depending on the system and allocation size, there is no perfect solution. I'll try and find out the official word on rendering, if JOIN'd is really any better, my guess is like I said, polygon count of the individual objects and number of objects.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2003 at 14:37, xxxxxxxx wrote:
(?, Of course you're right that your method is better, but my comment was strictly on schemes for allocating memory on-the-fly without knowing the amount in advance. And object resizing *does* involve dynamic array allocations. Given that pre-calculation were out of the question I'd be surprised if double-after-full weren't one of the better methods for allocation. I cannot think of many algorithms for which pre-calculation wouldn't be possible with two passes though...)
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/02/2003 at 01:16, xxxxxxxx wrote:
I've had other discussions with people on dynamics allocations, I'm one not in favour with the double method, since I don't like the idea of allocating 256MB when I only need 129MB when talking just plain old boring memory allocations where you really have no way to know the final size, or an approximate upper estimate of the final size (say from a hardware source that simply feeds in data), then sure, it is a valid method, just like adding a fixed size is, one is a trade off of waste against a bit extra speed, the odd extra block allocation is not that bad, personally I prefer the fixed size method, where the size of each block is a good estimate, or a tested trade off, allocating one block of memory isn't much overhead, allocating 10,000 or so starts to build up, you get into a million allocations and you can go make a cup of tea
I think we may have gone a little OT here, the initial points were hints/tips for better generator objects, I was just saying I didn't agree (depending on wastage) that allocating a single large object then filling only what you wanted was a good thing for generators, as I said, I guess it depends on waste, if you are talking about wasting a few Kb, probably no problem, if we're talking MBs then IMHO it is a serious problem!
Imagine a hair geometry object, say one from S&H a fairly low hair count is 20,000 hairs, into polys you get an object around 24MB, so lets say I'd increased the count just enough to get it to 33MB, the double-after system would have allocated me 64MB (say, depending on where you'd say your initial starting point and since you don't know that too is a guess)...
So now the scene is cloned for render to the picture view (or NET for that matter), so that 64MB is turned into 128MB (64 in the editor, 64 in the picture viewer), so I now have nearly 64MB of memory allocated I'm not actually using, and worse, when the clone happened, CINEMA had to copy all the unused data too!
You also have to keep in mind what affect all that extra data (unset, unused) might have on other areas of CINEMA, a deformer for example, that deformers EVERY point, so in this case, you could have many many unused points it will now have to deform, and worse, it also has to clone them each time see where I'm going with this! IMHO, allocate when you need, no more, it might look faster for you at the time, but when you come to use it, you're actually making it worse.
Just one thing comes to mind having re-read this thread (Paul) you said you were filling a mesh, if it ran out you added extra (resize, double or fixed?), was this points and polygons? then do you resize it back down at the end (to fit the exact number)? you weren't clear on that bit
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/02/2003 at 01:38, xxxxxxxx wrote:
So now the scene is cloned for render to the picture view (or NET for that >matter), so that 64MB is turned into 128MB (64 in the editor, 64 in the >picture viewer), so I now have nearly 64MB of memory allocated I'm not >actually using, and worse, when the clone happened, CINEMA had to copy >all the unused data too!
no , i think you missed the point.
if you have 32 mb, then you run out , you alloc another 32mb sao you got 64.
you run the rest of your calculation and only needed another 5mb.
once your finsihed , you resize for 37mb and return the object.
there is no wastage , its a temporary buffer , nothing more.
it just saves you having to realloc on the fly / per hair ,ect.
>You also have to keep in mind what affect all that extra data (unset, unused)
nothing goes unused , cos you clear this "cache" when the object is finished.
nice thread
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/02/2003 at 01:45, xxxxxxxx wrote:
Just one thing comes to mind having re-read this thread
I geuss the max size .I can almost always say , it will be less than xxxx mb
cos I dont want to be doing a full resize half way through .
>was this points and polygons?
yes
>then do you resize it back down at the end (to fit the exact number)? you >weren't clear on that bit
yes , exactly
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/02/2003 at 01:50, xxxxxxxx wrote:
ROTFL! think we've been talking across each other that is why I suddenly asked if you were doing that (resize at the end), it didn't sound like it (to me), then I got thinking, well, hang on, what about all those unset polygons! in one of my previous rants I put:
"2> NO NEVER! you should never repeat using resize over and over"
So yes, you are completely correct not to keep resizing
As a temporary allocation system, it doesn't make much difference what system you use, provided it doesn't grow too stupid and you hit virtual memory that is one of my reasons for preferring the fixed size method (rather than double) you have more control to keep the jumps low.
Just a slight OT again, I have not tested the speed issues (but I will), you can also consider not allocating an object until you do know the size, instead buffer the data, probably a MemoryPool, then when you have all the information, create your object and fill it. I don't know if this is faster or slower, or about the same as resize getting called for each block and then to cleanup. I use the buffer method in S&H since I have no choice, the data returned to me is per hair and in its own memory block, so I just cache these until I have them all ready to build the object. Might be useful to know some rules for generators and methods for creating them, I don't know how common it is to not know your final size, especially if your own functions are creating the geometry.
Glad we cleared it up, you got me wondering what you were doing there for a minute next time I'll ask and not leap