Jump to content

Archived

This topic is now archived and is closed to further replies.

3D-Pangel

C4D Viewport Performance - Can We Get The Truth Behind It?

Recommended Posts

I don't know where you got your know how on multithreading, but it is definitly not "super easy" to "multicore" hair. It's actually one of the most difficult software engineering tasks to find viable multithreading solutions for this kind of problems.

You probably do know about a million times more about computer programming then I do.  I was looking at it from the perspective of the hair preparation for rendering getting multi cored easily by the user by using multiple hair objects.  You can try this out.  Make more then one hair object then hit render.  Each hair object will use a different core for the render preparation of the hair.  For a more proper way to multicore hair it seems to get more complicated, but this was my thought.  Without hairs interacting with each other the physics calculation for each hair reacting with stiffness, gravity, etc. could be handled by a separate core.  This is because the the calculation of position of one hair does not effect the others.  If the hairs do interact with each other this becomes more complicated to multicore, but theoretically can be done to an extent.

To get even more into it lets take a look at the Hair Material.  The hair material has things like Kink, Frizz, Density.  These things can be multicored in the following way.  Have each parameter like Kink, Frizz, etc. calculated by a different core independently.  After done the positions each core came up with can be averaged out to get the modified position of the hair.  I could go more into it if you like giving more and more specifics of how many different ways it can be multicored.  If you like PM me about something more specific that you are having trouble multicoring and I'll try to figure out a basic outline or more specific outline as to how it can be multicored.  I don't know why, but I like to figure out puzzles like this.  Maybe I wouldn't be able to help because the team over their already thought of the best way to optimize it, actually I expect the team over there has though of everything I said, but maybe I could contribute a little.  Won't know if we don't try.  I made theories on how many different parts can be multicored not just hair.

Embree from my tests is much faster then QMC.  The way I tested it was using the render engine Corona Render which uses the Embree core and something called HD Catch.  If Corona is any sign of how much faster Embree is then it is about 50x faster in most scenes when compared to the QMC C4D uses now.  Perhaps making a plugin for Corona would be easier then integrating Embree?

Share this post


Link to post
Share on other sites

Fastbee, i appreciate you want to help, but this is a lot more complicated than it looks on the surface. What you see is completely independent objects beeing processed in parallel. Once they aren't independent anymore things become realy ugly.

Share this post


Link to post
Share on other sites


What you see is completely independent objects being processed in parallel. Once they aren't independent anymore things become realy ugly.

 

^ This.

For primitive objects it's not a problem, but once dependencies kick in, then things could get unstable pretty quickly. (Generators that require input objects like Hair/NURBS/MoGraph/Cloth, Deformers like Correction and Skin,  Expressions like Dynamics Tags and XPresso, etc.)

 

Before we can even think of doing multi-threading for objects/tags, IMO the core engine has to be revamped to make multi-threading stable. (Right now the Priority system is hamstringing C4D in that department. It brute-forces execution orders, basically it does things in the order you have in the OM and in the priorities one after the other. It doesn't really do any priority 'management' or optimization at all.) This by itself would take a lot of development time, and would create huge internal changes like from the shift from R11.5 to R12.

Share this post


Link to post
Share on other sites


Before we can even think of doing multi-threading for objects/tags, IMO the core engine has to be revamped to make multi-threading stable. (Right now the Priority system is hamstringing C4D in that department. It brute-forces execution orders, basically it does things in the order you have in the OM and in the priorities one after the other. It doesn't really do any priority 'management' or optimization at all.) This by itself would take a lot of development time, and would create huge internal changes like from the shift from R11.5 to R12.

 

I'm pretty sure modo does it in the same way except it goes from the bottom up in its Item List. Yet it's faster than C4D (now with 701).

Share this post


Link to post
Share on other sites

@srek

 

I think that It's really nice of you to explain this things in the best way you can and in a simple manner so that we understand them.   You never start googling all over the place nor go the fanboy way of quoting everything you can find on google acting like you know a lot,  In your case you do know tons :)

 

Thank you

Share this post


Link to post
Share on other sites

I will add my input,  a company also has to look at all the user bases.  a program would have to be able to use what hardware is available to a customer, if the new software is made to run on a computer with 100 core 50 terabyte speed, it will also have to run on a single core 5 meg speed or you will be cutting the customer base and thereby ones profit, such solutions are not all that easy.

 

just my humble opinion


I don't have a dirty mind because I use Mental Floss.

Share this post


Link to post
Share on other sites

Fastbee, i appreciate you want to help, but this is a lot more complicated than it looks on the surface. What you see is completely independent objects beeing processed in parallel. Once they aren't independent anymore things become realy ugly.

You hit the nail on the head with this.  The secret to multicoring in my brain is figuring out where or how the different things can be split up to process them independently.  If that can't be done, it is not only ugly to do it is impossible to do.

Let’s take one of the most seemingly complicated things to multicore which is cloth.  I would write up this for anything if you can think of something more complicated to multicore then cloth I'll do that.

 

With cloth simulation each points position is seemingly connected to the other points through invisible springs of sorts.  Taking it one step at a time each point can first be calculated independently to see if it has intersected with any geometry.  No geometry interactions we now go to how cloth affects itself.  To simplify it to begin with I’ll say the cloth has no squash or stretch or tear at the beginning here.  Stretch will be added later.  Now the cloth needs some forces acting on it or it’s not going to do anything.  Gravity is easy as it works on every point the same.  Adding air resistance we now get a drag that will react differently on each part of the cloth.  If, the drag is represented by 2D vectors, then each vector can be seen to affect the cloth independently.  Now we start calculating the deformation of the cloth.  Force = mass x acceleration.  If the mass is equal among the 2d surface the acceleration of the of the cloth with the greatest force should be the part that accelerates the most.  If the cloth had already been in movement I think the equation would be position = mass x acceleration ^2 + 2 x velocity + position could be used on every point to find the one that would have the greatest change in position.  Either way, after the position is found for every point, one core per point, an average needs to be done incorporating a falloff between were the points want to be and where they have to be so the cloth is not ripped or stretched.  Let’s say there was a brief impact force that only worked on a single point in the middle of the cloth, but that point would have had it’s point’s position moved pretty far.  After the points positions are averaged with a 2D falloff for that point that was moved pretty far and adjusted so they are the right distance from each other it should look like a little mound or head that way if no other forces then act on it.  If the cloth can stretch, it will now not complicate things like we would have though when we first started thinking about how to multicore cloth at the start.  In the impact situation above the stretch of cloth add another force to the points of the cloth.  This new force can be calculated independently of the impact or drag forces for each point of the cloth then have the cloths positions averaged like before with some kind of falloff per point, but this time the average can be adjusted by possible stretch factor dependent on the stretch amount allowed.  If an object hits the cloth, it can be done like another independent force added to the rest.  Each independent force acting on each independent point can be calculated by a different core.  With fixed points the points can be given a force to begin, then during the phase where adjustment is being made so the cloth does not rip the fixed points would be put in position first and have other points based off of that spreading the rest of the cloth in a spherical way.  This way if a single point was fixed at the corner of a 2D cloth the next 3 points could use 3 cores then 5 and so on.  Just like that we managed to multicore something that seemingly would have been impossible to multicore by figuring out where and how the processes can be split.  Again, I could go into more detail if wanted.

Share this post


Link to post
Share on other sites

Please don't be disapointed fastbee, but this is still way to simplified. It doesn't start to take into acount what happens if you drag cloth over an uneven surface, let alone over an edge, spikes or through a hole. Don't start thinking about trapping cloth in geometry (armpit etc.). This is realy complex math, way way out of my league. Some time ago one of the devleopers did show me the basic math to solve this and yes, i had seen some of the symbols before when i went to the polytechnical, but i wouldn't even know where to start reading or understanding this.

Cheers

Björn

Share this post


Link to post
Share on other sites

Fastbee - why not apply for a job at Maxon? They are currently looking for a developer and there have previously been developer jobs going.

 

What I'd like them to do first is have a proper symmetry modelling mode. No need for multi-threading.

 

3DKiwi

Share this post


Link to post
Share on other sites

Please don't be disapointed fastbee, but this is still way to simplified. It doesn't start to take into acount what happens if you drag cloth over an uneven surface, let alone over an edge, spikes or through a hole. Don't start thinking about trapping cloth in geometry (armpit etc.). This is realy complex math, way way out of my league. Some time ago one of the devleopers did show me the basic math to solve this and yes, i had seen some of the symbols before when i went to the polytechnical, but i wouldn't even know where to start reading or understanding this.

Cheers

Björn

Uneven surface, over a edge, spikes and through a hole.  OK.  I'll go about them one at a time using the same method as I had described in my last post.  Those steps being as follows for all cloth situations.

 

1)  Calculate the position each point of the cloth would be at based on the previous position, velocity, and acceleration based on forces acting on it without taking into consideration at this point restriction of movement because a point is fixed or cloth internal forces.  Assume even mass unless a mass mapping was used to vary mass over the cloth.

 

2)  Translate the position data to 2D maps with the greater the points were from their last position equaling greater strength.  Depending on what kind of cloth each point change in position could be a bell curve effect on surrounding points or anything to make the cloth look right.  This 2D UVish map generated for each point of the cloth will be added together to be the internal forces the cloth exerts on other points of the cloth.  Force due to previous stretching of the cloth or stiffness (force repelling other points) can be done in part 1 since those forces would work in a single vector direction along the plane of the cloth stretch or stiffness.

 

3)  Positions are adjusted to take into consideration internal forces calculated in step 2.

 

4)  Now for fixed points and when cloth bumps into a surface.  Any fixed point or surface the cloth bumps into could potentially exert an infinite force on the cloth.  This would mess with the cloth calculation in a big way.  Instead let’s take the position calculated in step 3 and use it with the points we know are fixed.  Move the point or points of the cloth to the points we know are fixed because they have to be there no matter what.  Now move all the other points as close as possible to the calculated position in step 3 without going past the limits of how far the cloth can stretch based from the fixed points.  At this stage if a point would be through a surface based on position info of step 3 it must be limited to being on the surface instead of through the surface and be given a bounce force for step 1 of the next frame if it has a bounce. 

 

Cloth going over an uneven surface would probably give multiple points where the position after step 3 would be through the surface.  These points would be restricted to the surface as described in step 4 since the points went through the surface which is impossible.  There would also be a friction force which could be added in step 1.

 

Cloth going over an edge would have the friction calculated in step 1 as well as points  calculated after step 2 going through the surface due to gravity and would have the part on the table have those points restricted to the surface as described in step 4.  The point going over the table would not have the restriction of the table, but would have the restriction of the points on the table not being able to go through the table.  This would make the points going over the table probably be higher then they would want to be if not for the correction in step 4.

 

Spikes should be same or similar to an uneven surface.

 

Cloth through a hole should be similar to the cloth going over a table except the points pulling the cloth through the hole are also an absolute position to be corrected for in step 4.  Stiffness forces calculated in step 1 would become great as the cloth gets closer together.

 

Please show this to someone other MAXON srek.  Maybe they will get an idea from it that can be incorporated at some years in the future.

 

 

Fastbee - why not apply for a job at MAXON? They are currently looking for a developer and there have previously been developer jobs going.

 

What I'd like them to do first is have a proper symmetry modelling mode. No need for multi-threading.

 

3DKiwi

Thanks 3DKiwi.  I wouldn’t mind moving to Germany, or learning German, and programming, but my programming skills are probably not good enough at the moment where MAXON would even consider hiring me.  Plus, there is the general thing where companies do not hire people to think.  They just want to hire someone that will do what they tell them to do without thinking.  I don’t have a problem with doing only what I’m told to do, but I really doubt someone would hire me to think all day long solving problems like the cloth multicoring problem above.  I also have a BS degree that I can’t use despite sending out multitudes of resumes because my GPA was not high enough in school and my prior work experience is non existent.  Thus, I am forced to freelance it as a 3D artist.  If MAXON did want to hire me in any way I would jump at the chance.  If anyone would hire me for anything full time I would jump at the chance.  For good companies like MAXON I would be happy to work with them full time, part time, or as an independent.

 

I'm with you on the proper symmetry modeling tool, maybe a bevel nurbs object, having multiple networked computers work on a single frame without having to use the tiled camera, adaptive geometry with the sculpt tool, some painting tools in bodypaint, and a bunch other little things like an anisotropy parameter added to materials.  If the Lumas could work on the bump or normal channel, that might fix the anisotropy problem, but it doesn't want to work on the bump or normal channel.  Having a dedicated anisotropy parameter like some other render engines have would make it so much neater.  I do get why they work on the stuff they work on though.  A lot of things can be worked on, but a lot of people won't use them because they only use C4D for motion graphics.  It seems in 3D programs your either the best at something or people will use another program which is the best at doing that something.  For MAXON to expand they would have to choose a field, like character animation, and put a ton of time and good planning into it to be the best at that field.

 

Guess I'm just going on about different random things now so I'll stop.

Share this post


Link to post
Share on other sites

Thanks 3DKiwi. I wouldn’t mind moving to Germany, or learning German, and programming, but my programming skills are probably not good enough at the moment where MAXON would even consider hiring me.

 

I think about of half their programmers don't live in Germany. One lives and works for them from here in New Zealand. But yes you would need strong C++ skills plus prior 3D app or similar experience. I think some of the current programmers got into it by writing plugins for C4D.

 

3DKiwi

Share this post


Link to post
Share on other sites
  • Topic Author
  • You hit the nail on the head with this.  The secret to multicoring in my brain is figuring out where or how the different things can be split up to process them independently.  If that can't be done, it is not only ugly to do it is impossible to do.

    Let’s take one of the most seemingly complicated things to multicore which is cloth.  I would write up this for anything if you can think of something more complicated to multicore then cloth I'll do that.

     

    With cloth simulation each points position is seemingly connected to the other points through invisible springs of sorts.  Taking it one step at a time each point can first be calculated independently to see if it has intersected with any geometry.  No geometry interactions we now go to how cloth affects itself.  To simplify it to begin with I’ll say the cloth has no squash or stretch or tear at the beginning here.  Stretch will be added later.  Now the cloth needs some forces acting on it or it’s not going to do anything.  Gravity is easy as it works on every point the same.  Adding air resistance we now get a drag that will react differently on each part of the cloth.  If, the drag is represented by 2D vectors, then each vector can be seen to affect the cloth independently.  Now we start calculating the deformation of the cloth.  Force = mass x acceleration.  If the mass is equal among the 2d surface the acceleration of the of the cloth with the greatest force should be the part that accelerates the most.  If the cloth had already been in movement I think the equation would be position = mass x acceleration ^2 + 2 x velocity + position could be used on every point to find the one that would have the greatest change in position.  Either way, after the position is found for every point, one core per point, an average needs to be done incorporating a falloff between were the points want to be and where they have to be so the cloth is not ripped or stretched.  Let’s say there was a brief impact force that only worked on a single point in the middle of the cloth, but that point would have had it’s point’s position moved pretty far.  After the points positions are averaged with a 2D falloff for that point that was moved pretty far and adjusted so they are the right distance from each other it should look like a little mound or head that way if no other forces then act on it.  If the cloth can stretch, it will now not complicate things like we would have though when we first started thinking about how to multicore cloth at the start.  In the impact situation above the stretch of cloth add another force to the points of the cloth.  This new force can be calculated independently of the impact or drag forces for each point of the cloth then have the cloths positions averaged like before with some kind of falloff per point, but this time the average can be adjusted by possible stretch factor dependent on the stretch amount allowed.  If an object hits the cloth, it can be done like another independent force added to the rest.  Each independent force acting on each independent point can be calculated by a different core.  With fixed points the points can be given a force to begin, then during the phase where adjustment is being made so the cloth does not rip the fixed points would be put in position first and have other points based off of that spreading the rest of the cloth in a spherical way.  This way if a single point was fixed at the corner of a 2D cloth the next 3 points could use 3 cores then 5 and so on.  Just like that we managed to multicore something that seemingly would have been impossible to multicore by figuring out where and how the processes can be split.  Again, I could go into more detail if wanted.

    You are correct in stating that cloth is really a mesh of points inter-connected by springs.  But your solution only describes how each point should react when enacted upon by an outside force such as wind or gravity.  At which point there is some  averaging between the point positions to account for cloth stretch, etc.  Well, that won't give you very good cloth dynamics.  To do it right, you need to consider that every point on the cloth moves at a rate proportional to the sum of the forces acting on it from the neighboring points.  This means that you can NOT just rely on interpolation of point positions as you described.  The simulation must proceed linearly with every force on each cloth "spring" being recalculated with each new position.  Therefore, position n+1 can only be determined after all the spring forces have been solved for position n.

     

    It is that inter-dependency which makes multi-threading difficult - you simply cannot divide it up amongst the cores as you will break that interdependency.

     

    Splitting up simulations such as cloth or fluids amongst different cores or machines was a huge problem that was finally cracked by ILM in 2006 for the large scale fluid simulations in the movie Poseidon. There was no way that they could have finished that movie on time unless they could use a render farm to calculate the fluid simulation (in their first go, they let a single machine run the calculation.  After a week of calculation, they realized that there had to be a better way----and that was only doing the force field calculations...nothing was being rendered yet).

     

    Four Phd's later and they had a solution.  One of which is (IMHO) the true god-father of all of today's SFX -- Ronald Fedkiw (a professor at Stanford University).  He doesn't design the VFX, but he's the guy behind the mathematics which make everything possible.  He also plays against type....the first thing that comes to mind of a Standford mathematician specializing in such esoteric fields as "level set theory" is a skinny, grey-haired nerd wearing glasses and an argyle sweater vest. 

     

    Nope...he's also a competitive body builder.  Hrvoje would love this guy!

     

    Dave


    Sorry...but I simply do not have enough faith to be an atheist.

    Share this post


    Link to post
    Share on other sites
    Guest
    This topic is now closed to further replies.

    • Recently Browsing   0 members

      No registered users viewing this page.

    YOUTUBE CHANNEL:

    ABOUT US:

    C4D Cafe is the largest CINEMA 4D community. We provide facilities for discussion, showcasing and learning our favorite software :)
    ×
    ×
    • Create New...