CGTalk > Software > Maxon Cinema 4D
Login register
Thread Closed share thread « Previous Thread | Next Thread »
 
Thread Tools Search this Thread Display Modes
Old 12-07-2012, 02:09 AM   #16
wesware
what the?...
 
wesware's Avatar
portfolio
Wes Ware
Wes Ware Creative
Nashville, USA
 
Join Date: Sep 2002
Posts: 1,284

On a side note... the workaround video uses a hypernurb object to subdivide your bake mesh, then made editable. Only problem with that is the hypernurb object seems to have a limit of 6. So you're better off using hypernurb subdivide in addition to that or instead of.... if your sculpt was divided more than the hypernurb object will allow. Make sense?
__________________
Making googlie eyes for over ten years.
Wes Ware Creative
 
Old 12-07-2012, 07:35 AM   #17
dataflow
Expert
 
dataflow's Avatar
portfolio
james hooten
digital media
TAFE
Sydney, Australia
 
Join Date: Dec 2006
Posts: 1,065
Quote:
Originally Posted by wesware
On a side note... the workaround video uses a hypernurb object to subdivide your bake mesh, then made editable. Only problem with that is the hypernurb object seems to have a limit of 6. So you're better off using hypernurb subdivide in addition to that or instead of.... if your sculpt was divided more than the hypernurb object will allow. Make sense?

its funny iv never notice that the hypernurbs stops at 6i usaully never go past 3.
you could always just subdivide (hypernurb) it more then once.
__________________
Dataflow Donation Cinema 4D Beta Tester
 
Old 12-07-2012, 09:49 AM   #18
dataflow
Expert
 
dataflow's Avatar
portfolio
james hooten
digital media
TAFE
Sydney, Australia
 
Join Date: Dec 2006
Posts: 1,065
interactiveBoy what are the other issues you contacted maxon about?
__________________
Dataflow Donation Cinema 4D Beta Tester
 
Old 12-07-2012, 03:03 PM   #19
interactiveBoy
Expert
 
interactiveBoy's Avatar
portfolio
Gary Ingle
Animator / Composer
Nashville, USA
 
Join Date: Jul 2005
Posts: 713
They have to do with Physical Render. They have been confirmed issues. I feel they are bugs, they call them limitations. Semantics.

1) When using particles with Physical Render and motion blur turned on, as the particles die, they internally change their index number. This confuses the motion blur so you end up with frames of flashes of white or certain frames not looking like the same color range as other frames. It's due to the index ID's changing on all the particles and the motion blur interpolating a particle from its previous index number (which was a different particle altogether)
Solution: NONE
Workaround: don't let particles die. Set their lifetime to be as long as the segment you are rendering so no particles will die.

2) Animating light brightness when using Physical Render. If you intend to fade lights to 0% there is a good chance you will get white flashes or complete shifts in color at the time (frame) that the light goes to 0%. When a light goes to 0% it is removed from the scene, thus that index number is gone, and all the other lights shift to a new number ID.
Solution: Sounded like there was no fix planned when I talked to tech support.
Workaround: Never set the light's brightness to 0%. Instead go to 0.01%

Couldn't this be fixed on their code? I understand killing off particles for memory reasons, but if the "fix" is to never let them die anyway, then why keep that in the code which is causing MAJOR render glitches?

As for the lights, why kill them off at all? Couldn't they keep their index numbers? How much memory could that really be taking up? I'm no coder. These are just hypothetical questions.

Also on number 2, I requested that they code it on their end (since it is a "limitation" with their render engine). I asked why not have the code convert 0% to 0.01% under the hood when physical render is the active render engine. Seems like it would be an easy fix in the code.

I have started compiling a C4D Bible here. Sadly, it is not a gospel. It is a book of sins. LOL

I have to document all these workarounds we have to do. It's getting to be a real nuissance to our workflow.

Last edited by interactiveBoy : 12-07-2012 at 03:07 PM.
 
Old 12-07-2012, 03:10 PM   #20
Venkman
Don't cross the streams
 
Venkman's Avatar
portfolio
Peter Venkman
Frederick, USA
 
Join Date: Sep 2003
Posts: 3,526
Quote:
Originally Posted by interactiveBoy
They have to do with Physical Render. They have been confirmed issues. I feel they are bugs, they call them limitations. Semantics.

1) When using particles with Physical Render and motion blur turned on, as the particles die, they internally change their index number. This confuses the motion blur so you end up with frames of flashes of white or certain frames not looking like the same color range as other frames. It's due to the index ID's changing on all the particles and the motion blur interpolating a particle from its previous index number (which was a different particle altogether)
Solution: NONE
Workaround: don't let particles die. Set their lifetime to be as long as the segment you are rendering so no particles will die.


That one doesn't seem like much of a workaround!
 
Old 12-07-2012, 03:11 PM   #21
interactiveBoy
Expert
 
interactiveBoy's Avatar
portfolio
Gary Ingle
Animator / Composer
Nashville, USA
 
Join Date: Jul 2005
Posts: 713
I know, right? Not good. You'd have to play with the age settings and visibility or transparency or something like that so they appear to have the shorter life cycle.
 
Old 12-07-2012, 10:54 PM   #22
Darter
Positive buoyancy
 
Darter's Avatar
David Wickenden
Ballina, Australia
 
Join Date: Nov 2003
Posts: 1,213
Quote:
Originally Posted by interactiveBoy
1) When using particles with Physical Render and motion blur turned on, as the particles die, they internally change their index number. This confuses the motion blur so you end up with frames of flashes of white or certain frames not looking like the same color range as other frames. It's due to the index ID's changing on all the particles and the motion blur interpolating a particle from its previous index number (which was a different particle altogether)

I'm not sure what's happening with Physical Render but when particles die, the remaining particles retain a constant internal index. This can be seen by printing the Particle output from a PPass node. If this weren't the case particles with e.g. spin applied would rotate eratically as other particles died. When particles within a group die, the group indices (PPass Index port) of the other particles do change.
 
Old 12-10-2012, 02:20 PM   #23
interactiveBoy
Expert
 
interactiveBoy's Avatar
portfolio
Gary Ingle
Animator / Composer
Nashville, USA
 
Join Date: Jul 2005
Posts: 713
Hey Darter -

Thanks for posting that. I had never tested it myself. The description I gave above is the exact explanation I got from Maxon tech support.

Who knows what the issue is then. Perhaps that is why they have been unable to fix it.
 
Old 12-10-2012, 03:35 PM   #24
chi
Modernism at my brains
 
chi's Avatar
portfolio
Patrick Goski
Community Ambassador (North America)
MAXON Computer Inc.
Montreal, Canada
 
Join Date: Dec 2001
Posts: 1,750
Send a message via MSN to chi
Quote:
Originally Posted by Darter
when particles die, the remaining particles retain a constant internal index.


Regardless of the exact details
The issue is that if particle 20 dies the motion blur, which looks from frame to frame to calculate blur, doesn't know how to deal with the missing particle. The particle didn't move to a new location, and it no longer exists as an object. result, MB failure.
Although it make sense in my head that "if an object doesn't exist, don't blur it." this is likely much harder to achieve in the program.

I would say this is a limitation because it would likely require extensive work to fix, rather than a couple lines of code....and the more extensive the work the more likely you are to see effects else where in the program.
And if the issue was inherent to TP, it doesn't make sense to bash Physrender to get it to work....the smarter route would be to fix TP. Which is much more work than a bug fix.

The workaround is to transfer the particles into a new group and hide them rather than actually kill them outright. My assumption would be once hidden you could then safely kill the particles. although I have not tested that one.

This is actually easier to do than the baking workaround

Anyway, continue to send examples of issues with baking and requests to MAXON. The better you can describe what you want, and where the current weaknesses lay, the better case you make for a fix.
__________________
The views expressed in this post are by no means the opinion of those making the post or of any one person in particular.
 
Old 12-10-2012, 03:35 PM   #25
CGTalk Moderation
Lord of the posts
CGTalk Forum Leader
 
Join Date: Sep 2003
Posts: 1,066,481
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 12:08 PM.


Powered by vBulletin
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.