Render and OpenGL are different

Hi all,

first post here, sorry to start with a troubleshooting one.
I’ve been testing Krakatoa C4D trial for about a week now. I grew enough fond of it actually, that I’d like to share some impressions in case the feedback is useful. First impressions are so far great. Very fast, and well, finally we have Krakatoa. The integration looks very well done also, even though I would welcome a more intuitive UI that matches what C4D users expect in terms of user friendliness. I had a hard time getting my head around having 2 values for parameters (e.g. exponent values) instead of just 1 value, or for the fact it is a separate renderer instead of an effect. Another example is repopulating, I’m still trying to figure out the value system works. Sometimes it gives me less particles, other times it just won’t increase them no matter the values.

Of course not a big fan of the complex and time-consuming FlexLM licensing system also, which is ironically inflexible, and I did get a random “license not found” error but thankfully after a restart it was working again. But I’m sure you have your reasons for using that.
I’m greatly fond of the ease of use of the C4D install, and most of its plugins which are license-file based and/or serial number locked. And if I have to change computer, I don’t have to get in any network-fiddling, support contacting, procedures to set it up, which are time-consuming.

Functionality-wise, I did notice some weird behaviors from time to time, like Krakatoa saving files into my project folder when I had disabled saving files from the render settings. Maybe there are again 2 settings for controlling that? And today, a more serious problem of getting completely different renders in the opengl viewport and in Krakatoa renders. I noticed it happened after scaling my scene, then I thought deformers were to blame, but now it happens without scaling and without deformers. I am using it with X-Particles, all objects have a scale of 1.

I tried caching x-particles but still the difference is obvious. The particles in the scene are cached.

krakatoa-hardwarePreview.png

A secondary problem is that I get a much darker render in the viewport than I do in the picture viewer. It seems viewport is taking alpha strength in account, thus being a more accurate, but I’m not really sure.
You can ignore the offset here because it is a screenshot of the viewport, and the size is mismatched.

Any ideas what could be causing these problems? Help would be much appreciated!

Maybe the solution from this thread will work?

viewtopic.php?f=202&t=11795

"Re: Viewport vs Picture Viewer render differences
Unread postby Bobo » Sun May 04, 2014 10:05 am

Uncheck the icon “Display the Color Profile in the Picture Viewer” and the image should match the default look of the viewport.
Hope this helps."

Did you cache the particles via X-Particles cache or Krakatoa PRT`?

I’d suspect this to be an error on the X-Particles side of things, as Krakatoa just renders what it gets fed particle-wise.

Hi caldreemn, thanks for the tip. I missed that post, it works fine now. I’ll have to look into the color profiles a bit more.

TylerAfx the particles are cached via X-Particles, since Krakatoa already gives an offset for them. I assume if I bake with Krakatoa it will bake them with the offset, but I can try it.

However with or without caching it still produces some severe offsets, it looks like I’m using a completely different camera (already checked that, and the render views). The x-particles renderer produces correct results.

I tried baking them with Krakatoa just now, and indeed they were quite offseted. The good thing is I am able to reposition the Krakatoa PRT Loader, and even scale it, so as a workaround I can sort of adjust them to their correct position after the baking.

This however seems like a bug. I could provide a scene file if you guys need it for examining the issue.

As a rule of thumb I would never use the X-Particles cache object, as its much slower than loading prts, and prone to errors/crash on loading etc…

TylerAfx, thanks for the tip.
It is indeed a lot faster, and stable-looking.