Messages

616

[Max] Resolved Bugs / Re: Removing Env Map while IR is on = crash

« on: 2016-06-06, 17:38:04 »

Definitely shouldn't happen.
Definitely not happening for me.

...maybe that env map was VrayHDRI? :>

Nope :) As per strict instructions we're using CoronaBitmap for HDR stuff (although it's painful... - rotations don't seem to work at all...). We're not having a lot of success working with it to be honest. Hope a dedicated CoronaHDRILoader is released... :)

617

[Max] Resolved Bugs / Removing Env Map while IR is on = crash

« on: 2016-06-06, 15:49:09 »

Not entirely unexpected behaviour I guess, but easily done...

Simply run IR and then remove the environment map from E&E window = crash.

Cheers,

618

Gallery / Re: Recent Spaces CONSTRUCT animation

« on: 2016-06-05, 07:59:28 »

Not that long, about 10 mins ish a frame and about 1400 frames. Rendered mostly on 3 dual Xeon beasts

beasts belong to hell!
But as Juraj mentioned: distributed or not?
If not, then beast is an understatement. :-)

No distributed rendering, no, just raw frames per machine. Most of our machines are dual 10/12-core E5s.

619

Gallery / Re: Recent Spaces CONSTRUCT animation

« on: 2016-06-03, 14:13:25 »

Thanks everyone. I'll let Iain respond about the technical stuff on this one.

620

[Max] Resolved Feature Requests / Re: Region/Crop In Interactive Render

« on: 2016-05-29, 17:59:12 »

+1 for this. Would be extremely handy to have a simple region/blow-up/stop/start/pause control directly in the IR window (both floating and viewport IR - we use both regularly).

621

Work in Progress/Tests / Re: corona 1.4

« on: 2016-05-28, 14:32:22 »

It's not a great idea to work in a bright UI like this. Apart from potential eye fatigue, the reason is that if you do, you will most likely overcompensate for what your eyes are seeing in the peripheral vision and your image will be a little off in terms of exposure etc. This is why it's also not a good idea to work with a pure black UI either and why most decent software packages these days have a solid mid grey UI. Shake and other compositing packages lead the way with this back in the day.

Goodness only knows why the devs behind PDPlayer feel it necessary to have their application solid blue... it's truly hideous.

622

[Max] Resolved Feature Requests / Re: Automatize Material ID Render Element

« on: 2016-05-25, 12:29:36 »

It should be possible for someone to script a simple version of this which does the following:

- for each unique material in the scene create a CoronaMask element and include all the objects with that material assigned to them

You can then Render Only Elements and there should be X number of mask elements - a simple b/w mask for each material type.

Now if someone can be bothered to do it... :)

623

Hardware / Re: xeon v4 cpus

« on: 2016-05-20, 12:09:28 »

Hi Alex,  feels like this is a Windows issue rather than a motherboard driver issue. 3dsmax and corona work great, it's just a couple of annoying things with win10

Ah right. Glad those two are working properly. That's what matters most I guess.

624

[Max] Resolved Bugs / Re: Corona Sun Crash in IR

« on: 2016-05-20, 10:52:31 »

I've never had this issue. I think you'll need to send them a scene where it happens reliably. Sounds very unusual.

625

Hardware / Re: xeon v4 cpus

« on: 2016-05-20, 10:31:40 »

ps. Juraj, i check the bios and its the latest one (which supports the e5 2697 v4 )

Hello mate. I spoke with Kern over at Scan about this a while ago and he mentioned that there were BIOS issues with these new chips, so we decided to hold off buying one. I would guess that this is the problem and that an update is needed from the mobo manufacturer (asus?). Although I imagine you've already been onto scan about this. We're thinking of plumping for the same chips you did so keen to find out what the problem is!

626

[Max] Bug Reporting / Re: Render Selected slower than expected

« on: 2016-05-20, 10:26:58 »

Turning off adaptivity helped enormously, but it's still painfully slow to use RS on a couple of small objects still. Hope this can be optimised.

627

[Max] Bug Reporting / Re: Render Selected slower than expected

« on: 2016-05-18, 12:54:16 »

Thanks Romullus. Going to test again now with adaptivity off and see if it helps! At the moment it takes the same amount of time more or less to render 1 object within a scene of hundreds... so it's basically only acting as a cookie-cutter rather than with any kind of speed benefit which you'd naturally expect.

628

[Max] Bug Reporting / Render Selected slower than expected

« on: 2016-05-18, 11:56:55 »

Didn't mean to make that title rhyme, but what can you do? :)

We're having a little trouble with render selected at the minute. With only one very small and fairly simple object in the include list, the render at 1080p still seems to take quite a long time to reach only 50 or so passes - in the region of around 2 minutes. We've noticed that this is helped a lot by using a region around the object, but this isn't practical for animation, which we're doing, since the object is visible across most of the frame, so the region would be the whole frame.

Are we doing something wrong here? Is there a way we can optimise?

Currently using daily build from April 24th. We *could* move to 1.4 for this if it would help?

Cheers,

629

News / Re: Corona 1.4 for 3ds Max

« on: 2016-05-16, 14:56:04 »

Congratulations guys, and RIP your web servers!

630

[Max] Daily Builds / Re: New VFB features

« on: 2016-05-11, 12:30:37 »

Unless im misunderstanding what u said wrote. I use the physical cam and mod for different  scenarios. By disabling the exposure control in max this enables u to use the one in the corona vfb instead. Its one or the other as far as i understand. Why would you need both?

What we are doing is simply using a CoronaCameraMod with exposure and tone mapping overrides on. What this does is instantly disable the CoronaVFB's own exposure and tone mapping controls (since it's taking those values from the CamMod). What we want is a dynamic link between the VFB and the CamMod so the VFB takes the values from the CamMod and then you can still tweak them in the VFB, with the new values then updating in the CamMod when you finish/cancel the render. In this way you can still tweak these values with a live render going on, which is hugely helpful. Currently we're kind of forced to use the IR to handle this, but it's not an ideal situation. Hope that makes sense.

I think we had this discussion about a year ago, I did suggest your solution :- ). I think it was technically impossible or something. To be honest though, I don't think Vray succeeded in doing this either or did ? I know Vlado contemplated live-link as well.

Yeh we did I think :) I have no idea if it is possible. What I could imagine might work is if when you hit render, Corona shifts all the values from the CamerMod into the VFB and "disengages" them from the CameraMod for the render, allowing you to tweak them in the VFB. At the end/cancel of the render it could then pipe them all back into the CameraMod if they have changed and disable them again in the VFB.