Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Ludvik Koutny

Pages: [1] 2 3 ... 157
1
Does anyone else also have the problem of a super slow scene after using Prune Scene to remove the virus?
It takes up to 5mins to open a file that used to be infected. Same with the Corona Interactve - it takes much longer to start now.

You could try this: https://www.sinisoftware.net/index.php?option=com_content&view=article&id=12&Itemid=195

Generally, what you describe happens if there's a high number of certain items 3ds Max often tends to create for no reason, such as retimers.

2
Corona for Blender / Re: Blender 2.80 or Corona 2.0?
« on: 2018-06-28, 10:21:41 »
2.8 definitely

2.8 will attract a lot more users to Blender, and likely, many of them will be looking for something better than Cycles, at least for achviz. Therefore it makes a lot more sense :)

By the way thank you very much for all the effort put into the exporter! :)

3
Feature requests / Re: The most wanted feature?
« on: 2018-06-23, 07:46:45 »
PBR will only change workflow, not really output quality. There is nothing that *looks* better with PBR, it just makes good looking things a bit easier to set up if your input is PBR set of maps. But talking about just a raw material, anything an average PBR material, such as Disney PBR, can do, can be replicated using CoronaMTL.

If we are talking about Principled material, then it's really just a workflow difference, not quality difference. Of course, I am not implying we should not have it. I am just saying that it won't make anything look magically better.

4
Actually, what I do to simulate V-Ray's checkbox is to use RaySwitch map instead of RaySwitchMTL. That way it's even easier to set up. Just plug CoronaRaySwitch map into your material's self illumination slot, and set all colors to the color you want your self illumination to be, but set GI color to black :) If it needs to be animated, then use for example CoronaColor map plugged into all the slots except GI slot, so that you don't have to animate all these 3 color swatches individually.

5
I am also a bit unhappy about fix not making it into a hotfix, since CoronaCamera is one of major 1.7 features, and at the same time, tilt/shift is so frequently used for ArchViz work. So the fact it does not work correctly pretty much removes CoronaCamera from 1.7 new features list for many ArchViz users as it can not be relied on yet. And its current state persisting until Corona 2 release will also probably make some users as skeptical about CoronaCamera the same way they currently are about 3ds Max Physical Camera.

Unfortunately, even the old Camera Correction modifier doesn't work with CoronaCamera.

6
Yes, I am also observing that in 1.7, Corona's interactivity is worst it has ever been. However I am getting bad results also in perspective view, not just with cameras.

7
General Discussion / Re: IR used to be interactive
« on: 2017-11-02, 17:19:20 »
There were quite a few IR performance regressions ever since 1.4, so they probably just added up. I've reported some of them, but they are still backlogged on mantis somewhere.

8
Why are you requesting MDL? Have you actually tried and found it useful? Or are you requesting it just because you know it exists?

9
Hehe, they were like "Wait a second, this looks too good to be rendered in our shitty Vue renderer" :D

10
I need help / Re: Pflow instancing not working
« on: 2017-09-30, 13:43:20 »
This is really sad, pflow without data operators is almost useless to me :(

You can still use pFlow with data operators, it will just mean particles will be unique geometry, not instances, so it will work exactly like it always did with all other renderers. V-Ray has VrayInstancer, which is kind of instance scattering tool, that can use pFlow particles to distribute instances, but you would not be able to use pFlow to affect mapping on those instances either. So in a nutshell, Corona is limited in this regard, but no other renderer does it any better. Ultimately, it's a limitation of old and obsolete Max/pFlow architecture.

11
Thanks guys for the comments, and thanks Ludvik for the FPS tips.  The screen refresh rate wasn't something that we had considered when putting this thing together.

However, we've had a fresh look at this and luckily there were enough extra frames to recompose the thing at 30fps.  The Vimeo link is now updated and should look a good bit smoother.

Thanks again guys!

Iain

There's still some strobbing on the edges perpendicular to camera movement due to the lack of motion blur, but the 30FPS framerate is a night and day difference on my monitor, looks awesome now! :)

12
About this forum / Re: Gallery images loading soooo slow
« on: 2017-09-27, 12:46:53 »

13
I need help / Re: Metals in viewport
« on: 2017-09-27, 12:42:10 »
Lot easier actually, I use this workaround also in V-Ray where refraction at 1.0 makes glass invisible.

Just plug for example CoronaColor set to complete black, or Output map with RGB Level at 0, or Multiply map with both slots set to black (pretty much anything that outputs just plain black color and is not slow) into diffuse slot of your material. You will then have correct black diffuse for metals in render. Now you can simply change your diffuse color swatch in your CoronaMTL to bright gray, to represent metal, but rendering will still use the map in the diffuse slot, and diffuse color swatch in CoronaMTL will be ignored, so everything will work right :)

14
There are 3 factors that contribute to movement judder:

1, 25FPS plays really poorly with 60hz screens (majority of them)
2, Sharp filters, or absence of softening (real cameras do not capture pixel perfect imagery, so CG sharp image filters are especially visible as strobbing on digital TVs)
3, Lack of motion blur. For some reason, almost every archviz animation misses motion blur, even the high end ones ;)

Ludvik,

Which frame rate would you use to diminish the judder?

Any, which will give you whole number when you use it to divide your screen refresh rate. For example 30 FPS:
60Hz/30FPS=2
120Hz/30FPS=4 (Means it would look nice on 120Hz TVs)

That's why you often see movies at 24FPS, to play nicely with TVs:
120Hz/24FPS=5
144Hz/24FPS=6

25FPS was standard for European TVs, because PAL standard (old European CRT TVs) Had 25Hz refresh rate (and ran on 50Hz interlaced/fields rate). US TVs, however, had NTSC standard, which ran at 29.97Hz (Which rounded well to 30hz (And again, it ran in interlaced mode = 59.94hz). And since most of the computer hardware originated in the US, US standards influenced mainstream refresh rates of today's computers screens (hence the 60hz mainstream), and since we are now in a digital age, and most of the TV content is now both made and broadcasted digitally, then even TVs these days adapt mostly US/Computer standards.

So in a nutshell:
24FPS will look good on most TVs, and won't look much worse than 25FPS on computer screens
25FPS will not look good on almost any computer screen, and may look good on some older TVs, and possibly on some new TVs too, due some smart adaptive mechanisms.
30FPS will look great on pretty much anything these days.

However, 30FPS is 16.7% more frames than 25FPS, so rendertimes/rendering resources are significant consideration.

Also, still, keep in mind that not using sharp CG image filtering for animation and -always, no matter what- using motion blur is equally as important to avoid judder.

15
There are 3 factors that contribute to movement judder:

1, 25FPS plays really poorly with 60hz screens (majority of them)
2, Sharp filters, or absence of softening (real cameras do not capture pixel perfect imagery, so CG sharp image filters are especially visible as strobbing on digital TVs)
3, Lack of motion blur. For some reason, almost every archviz animation misses motion blur, even the high end ones ;)

Pages: [1] 2 3 ... 157