Messages

1

General CG Discussion / Re: LUT

« on: 2017-07-15, 19:35:13 »

There really isn't much point to apply LUT to 32bit file in first place as it can't see that information nor output it.

I don't know, the extrapolation trick seems to work pretty well, doesn't it?
Also, in VFB+ it's applied in linear space and then gamma in applied after the LUT, is it not the same in Corona?

2

[Max] Resolved Bugs / Re: LUT clamps the image

« on: 2016-10-21, 17:29:49 »

just going with 45deg slope in overbrights, just shifted by the last value in LUT

This. Though kind of hard to think of it that way since it's not a 1D LUT. I would imagine using the same slope as the last segment of the LUT would cause unintuitive effects if the slope is negative or very steeply positive.

Negative values are clamped to 0.0, there's no extrapolation for those.

3

[Max] Resolved Bugs / Re: LUT clamps the image

« on: 2016-10-20, 07:47:39 »

VFB+ extrapolates for values outside of 0-1.

4

[Max] I need help! / Re: VFB+ and Corona Distributed Rendering

« on: 2016-08-20, 10:37:49 »

naikku, I have not received any email from you.

The issue of elements during render with Corona has been covered in this post: https://forum.corona-renderer.com/index.php/topic,10280.msg76635.html

Generally, if you render with VFB+ the render elements should be there when rendering is done. However, it seems that if you cancel the render then this doesn't happen. Since VFB+ doesn't make a distinction between a render that was cancelled and one that was completed then I'm assuming that Corona does not copy the render elements to the native 3dsmax buffers if the render was cancelled. Someone from the team should be able to verify.

5

Work in Progress/Tests / Re: romullus's wips

« on: 2016-07-18, 12:51:36 »

You didn't, glare was only recently added :)

6

Work in Progress/Tests / Re: romullus's wips

« on: 2016-07-18, 12:40:08 »

I see, I read your comment as implying that the Arion solution is real-time.
I haven't tried Arion, but making an educated guess I would attribute most differences in quality to better glare kernels.

7

Work in Progress/Tests / Re: romullus's wips

« on: 2016-07-18, 12:23:36 »

Here is result from VFB+. The glare is very complicated to setup there for true realistic behaviour, because power and size is unrelated. It's also not real-time, but computed like the one from ArionFx, although not as good as Arion. But it's kind of middle ground, and you can see it produces strong glare before massive star appears.

Indeed, glare from VFB+ looks much better, but if it isn't real time, then i'll stick withArionFX for the moment :]

Does ArionFX run on the GPU? I can't imagine it being that much faster with a CPU based solution.

8

[Max] General Discussion / Re: Bucket Renderer in 1.4 ???

« on: 2016-07-04, 16:25:32 »

A long time ago when I started a job as a 3D generalist, my supervisor told me that in order to make renders go faster, he opens the Windows task manager, and continuously holds down the F5 key.
This refreshed the CPU usage graph and made it look like the usage is more consistently at 100%.

Of course no one wants to hold down F5 all day so he cleverly automated the process by putting a weight on that keyboard key.

This taught me that developers can not rely on even the most basic assumptions about user understanding and behavior.

9

[Max] Resolved Feature Requests / Re: support Motion blur for change topology objects like fluid

« on: 2016-07-03, 17:18:27 »

Supported in VRay as far as I can remember, if the mesh contains velocity data. I'm not sure where it's looking for that data since 3dsmax doesn't define any data storage convention for vertex velocity information, but I remember it working with stuff like Realflow meshes, PRT files meshed with Frost, Alembic, etc.

10

[Max] Resolved Feature Requests / Re: EVO

« on: 2016-06-13, 11:33:16 »

Does look awesome but I can't figure out how it could possibly result in smaller files, when you consider any modern raytracing renderer would likely sample each pixel much more than once.

11

[Max] Daily Builds / Re: Adaptivity intenity slider?

« on: 2016-06-05, 15:34:52 »

Yeah, Lenscare is beautiful, used it on every (and I did very few sadly...) animation I've done, always satisfied.

VFB+ Dof is also pretty good but sometimes produces some unexpected result (sharp line in foreground shallow dof) although I again suspect this might be because of my incorrect z-depth setup.

VFB+'s Dof is improved since 2.6 version - it seems that in the end that goddamned sharp line was indeed a bug\some corona aa incompatibility and not our incorrect z-depth setups so it was fixed in 2.7 or at least I don't see much of it anymore )

Ah, didn't mean that :- ) Yes, that is solved, 2.7 is really good. I meant sudden lack of smooth transition, like if you would blur object within its boundary only.

That sounds like a typical artifact of setting the wrong "direction" for the depth buffer (white is near vs white is far). Could that be the case?

12

[Archive] Corona Scatter 2.0 / Re: Rotation Step in Corona Scatter

« on: 2016-05-30, 18:40:29 »

Why without spinner?

13

[Max] General Discussion / Re: Max Plugin vs StandALone

« on: 2016-05-30, 12:12:55 »

future DR without 3dsmax

This could be revolutionary for render farms, but how would you get around the issue of plugins?

14

[Max] General Discussion / Re: Corona Scatter - temporal stability

« on: 2016-05-30, 11:53:32 »

Last year I implemented a scattering solution for in-house use. My way around the deforming surfaces issue was to allow a mode of distribution which operates in UV space rather than object space.

This was usually needed when the artist wants to scatter objects on a deforming character. By using the UV data to distribute, I could ensure that the distribution would be consistent across different scenes, without requiring the artist to set up frame 0 or -1 as a consistent T-Pose.

Of course, this doesn't solve the collision detection issue which you describe. In my implementation, I left it to calculate collisions for the current frame only which results in objects popping in and out of existence like you describe. I have yet to think of a good conceptual solution for this issue.

15

Gallery / Re: Scandinavian housing visualisation

« on: 2016-05-26, 12:37:59 »

That's only partially accurate. Even if all highlights are compressed to <= 1.0, floating point 0.0-1.0 32-bit data is still more accurate than integral 0-255 8-bit data and you can perform more aggressive color correction on it without undesired artifacts such as banding.