Messages

31

News / Re: [fall 2013] Thoughts on development

« on: 2013-09-17, 16:08:24 »

HELL YEAH! :)

32

Corona Standalone / Re: Corona standalone build, input format description

« on: 2013-05-27, 19:09:29 »

33

[Max] General Discussion / Re: Vote for new Corona logo

« on: 2013-04-22, 23:03:33 »

Why not keep the "temporary" one? I like it. And besides, a logo is only what you made of it, marketing wise. On its own, it means nothing. :)

34

[Max] Resolved Bugs / Re: Corona and Deadline

« on: 2013-03-25, 23:51:30 »

Hey Loocas ! IT worked ! Thanks ! :)

   BTW, i am gettint a LOT of nodes spitting erros, saying that the processor don´t support SSE4.1. This is a problem with the type of processors used right ?

    This renderfarm is a mix of Dual, quad and OctoCore render Blades...

     

In that case, you have to distribute the correct version of Corona to individual nodes. Those nodes that are throwing this error need the LEGACY build of Corona. Just distribute the legacy plugins in the same way as described above on the problematic render nodes and you'll be all set.

35

[Max] Resolved Bugs / Re: Corona and Deadline

« on: 2013-03-24, 19:37:47 »

2013/03/19 20:55:16 ERR: Missing dll: coronautils2013.dlt - CoronaMtl
2013/03/19 20:55:16 ERR: Missing dll: coronautils2013.dlt - CoronaLight
2013/03/19 20:55:16 ERR: Missing dll: corona2013.dlr - CoronaRenderer

Well, that's your problem right here. :) Deadline, while launching 3ds Max, cannot locate the Corona DLLs correctly.

This can be caused by a number of things. Now, the best way to really make sure you're loading up the proper plugins is to create a special .INI file that you place in you REPOSITORY/Plugins/3dsMax (or, pretty much anywhere on the network so that all the machines can see it).

Another step is to make sure you have Corona distributed on ALL your network machines (render slaves). The easiest way is to copy the .dll corona files to the 3ds Max root installation folders (usually C:\Program Files\Autodesk\3ds Max 2013) and then the Corona plugin files to the plugins directory. For example: C:\Program Files\Autodesk\3ds Max 2013\Plugins\Corona

Again, and I have to stress this one, you have to distribute Corona on ALL of your computers, not just one, not just the server, but all of them and in the same path.

Then, create the .INI file, call it for example Corona2013.ini (assuming you're using Max 2013, but same applies to earlier versions). In the ini, place this code:

Code: [Select]

[Directories]
Corona=C:\Program Files\Autodesk\3ds Max 2013\Plugins\Corona
Save the file on your network, where it can be accessed by ALL of your machines.

Then, when you're submitting your jobs via the Deadline Monitor, just pick this file in the Advanced Options tab (see attachment).

Or when using the integrated Max submission script, the .ini file has to be prefixed with the "plugin_" name and it has to be saved in your repository/plugins/3dsmax directory, in order to show up in the Render tab options (see attachment).

Then, when you submit your 3ds Max jobs, 3ds Max will be able to correctly locate the Corona plugins and render your scenes on the entire network.

36

News / Re: Added support for Multiscatter, ForestPack

« on: 2013-03-24, 19:21:17 »

Cebas couldn't have done it for years and they still don't have Multiscatter support to this day.

So, my hat is off... KUDOS!

37

[Max] Resolved Bugs / Re: Corona and Deadline

« on: 2013-03-21, 11:12:58 »

Hey, kumodot,

what version of Deadline are you using and could you paste here a log from one of your slave machines just to see what is going on with the renders.

Also, just to make sure, you have the output setup correctly in the Max scene, right?

38

[Max] Corona Goodies - User Contributions / Re: LightLister for Corona Render

« on: 2013-02-05, 10:45:04 »

Damn, that was fast !! great news, thanks a lot for taking the time to do that :)

Yeah. One time I tried to make fR Light Lister and it was a HUGE PAIN IN THE ASS! I never actually finished it, since when I was done with version 1. Cebas changed a few params on the lights and I'd have to re-do the whole thing. :D

So, with that being said, kudos ecximer! Great work!

39

[Max] General Discussion / Re: New render settings layout concept

« on: 2013-02-03, 19:52:22 »

Now where have I heard that before Loocas ;-)

Hehe, yeah :) but you have to admit it's rather important from a workflow point of view. Hitting the TAB is just millions of times faster than navigating with a mouse. If you can expect logical behavior of the UI components, of course. :)

Thanks, Key, by the way!

40

[Max] General Discussion / Re: New render settings layout concept

« on: 2013-01-28, 18:46:56 »

I like the new layout better.

But, don't forget about the TAB Index. Many developers actually don't care about this, but when you deal with tons of settings and you just want to slightly adjust many of them on the keyboard, hitting the TAB key to jump from one to another is much faster and more convenient than selecting everything with a mouse.

The TAB Order should be layed out as follows:

within a group of controls: from LEFT to RIGHT from TOP to BOTTOM, making sure that you're going in this order only among controls for a single group, in other words, among controls that logically and functionally belong together.

41

[Max] General Discussion / Re: Gamma and linear workflow

« on: 2013-01-20, 23:22:13 »

I think I know what he means.

If I understand correctly, he wants to see the RAL 1000 rendered AFTER the gamma correction, which means that in order for him to get there, he need to first linearize the RGB values that represent RAL 1000, apply to the shader and then have it rendered out + gamma correct so that the output looks correctly like RAL 1000.

There are color pickers that support RAL and will give you correct gamma corrected results.

In the mean time. You can try saving a constant color from Photoshop of the RAL 1000 in sRGB or 2.2, load it up in Max gamma corrected and then use that value in your shader.

Or you can try this tool, for example: http://www.color-converter.com/ (I have no experience with it, I just googled it).

Or, if you're savvy with MAXScript, you can write this little formula for converting RGB to sRGB values and vice versa.

Code: [Select]

if (inputColor <= 0.00304) then
(
outputColor = inputColor*12.92
)
else
(
outputColor = (1.055 * (pow inputColor (1.0/2.4)) - 0.055)
)
This converts input RGB values to output, sRGB, values. Inverse the function to get the opposite result. Of course you'll have to apply this to all the R G and B channels individually.

42

[Max] General Discussion / Re: How should the frame buffer look?

« on: 2013-01-19, 19:12:31 »

I sometimes encounter interfaces that are so horrible (for example ... ribbon...)

I don't like Ribbon as much as anyone using AutoCAD or Max here, but, I have to say something. Microsoft put a TON of effort into Ribbon and actually made it work pretty damn well in Office, which was the sole point of Ribbon.

Ribbon is an Office designed UI that works in Office, but companies like Autodesk saw how flashy, sexy, hip and in this looks so they adapted it, mindlessly, in their applications, such as AutoCAD and Max, for no benefit to the users. I can do stuff that Ribbon provides much faster and with much less effort without the Ribbon than with it. The only real reason Ribbon is in Max is because it looks cool on the promo images and demo videos.

That being said, if Ribbon worked for the VFB well (which it wouldn't as it was primarily designed to get rid of super-deep nested/cascaded sub-menus that plagued Office), I'd be all for it.

The problem here I see is that this feature should not be democratically decided :)

Keymaster, or whoever responsible for the VFB, should gather as much data and input information from the actual users as they could and then and ONLY THEN should they hire a professional UX/UI designer that'd come up with a universal, fast and sleek GUI that'd be productive and useful.

I know myself what a UI/UX designer can bring to the table, when supplied with enough information and how important that is to the product and the end users in the end.

Again, Microsoft's thorough GUI research lead them to develop and design Ribbon for Office, which DOES WORK.
Autodesk's greed led them to implement Ribbon in Max, which DOES NOT WORK.

43

[Max] General Discussion / Re: How should the frame buffer look?

« on: 2013-01-19, 19:05:05 »

Yes, Luxology VFB is indeed nice, but also very slow. That's the point. I too would be happy for feature rich VFB, but i do not think GPU acceleration is something easy, and CPU version will never be fast with large feature set.

Agreed. But then, if you can't do it properly, why do it at all?

There are more important features to figure out, than a half-assed VFB that nobody will be satisfied with.

As for speed, Cebas' VFB (still in alpha, so, keep this info to yourselves :) ) is pretty damn fast and it features histogram, waveform for review and levels and curves for manipulation as well as some simple compositing tools ala Photoshop (layered stack) for quick comp checkups and PSD export. All works in real-time WHILE rendering.

If they can get it out fast and good as they did with the EXR import/export plugin, Autodesk will buy it, again, and all your work here will be for nothing as you'll be "forced" to adapt Corona for their own VFB.

AFAIK, that's their plan anyways.


So a custom VFB for Corona would be pretty damn low on "my" ToDo list, to be honest.

44

[Max] General Discussion / Re: How should the frame buffer look?

« on: 2013-01-19, 16:24:37 »

Honestly, i think that wanting VFB to be a complete post production tool and wanting it to be simple and fast goes against each other.

You should keep in mind that VFB will be most of the time displaying output while rendering, therefore CPU usage will be 100%. At such CPU usage, it's quite hard to get even raw output image without UI elements going at smooth and steady framerate as color mapping has to be recomputed on every interaction. Let alone VFB with dozens of gadgets.

GPU accelerate it then.

As for the features I described, these are essential. Period. Though, I wouldn't expect curves or levels to play along in real time while the output is being produced. But still, with GPUs today sitting idle while CPU rendering, anything's possible.

By the way, the Luxo VFB is pretty damn nice! I'm not too familiar with it, but from what I've seen, it's damn close to what I'd consider a great VFB.

45

[Max] General Discussion / Re: How should the frame buffer look?

« on: 2013-01-19, 13:49:24 »

Ok, to add a bit more constructive criticism to the debate, here are some examples of what I consider great viewers (vfbs, whatever you wanna call them):

Nuke (one of the very best) - attached

A pinnacle of usability. It's fast, simple, flexible and extremely customizable. Especially color management is at the cutting edge! Viewer processes are also pretty damn useful and great (create whatever nodes and combinations you want and the viewer will treat it as if it was a LUT! which is awesome). The comparison tools are top notch (wipe, fade etc...) and the toolbars are minimalistic, easy to recognize and easy to work with.

Corona should take this as a base for its VFB and copy the shit out of it.

RV - attached.

This is a tool I use for review and inspection. Mainly for animation, but the point is, it is a bloody good viewer. It's fast, robust and extremely flexible (you can customize and integrate the shit out of it). So, the main thing is, it has a great color management via LUTs, scripts and gamma settings. This is a MUST!

In a more extended usage scenario, you can load up several footages (incl. different source types, resolutions, color matrices etc..) then you can start comparing or combinig those in a layered fashion.

SpeedGrade:



I've added this one for the sole reason of the vectorscope, histogram and waveform displayed directly in front of the user.

Corona should consider these features essential.

So, the main purpose of a VFB is, basically, just review. You have to see and inspect what you're rendering. My top features would be:

• Simple
• Easy to the eye (no GUI bullshit)
• Have the option to turn on/off the HISTOGRAM
• Have the option to turn on/off the WAVEFORM
• Have the option to turn on/off the VECTORSCOPE
• Display render elements individually
• Inspect pixels, i.e. what color, alpha value, position, etc...
• Comparison tools would be nice, but not necessarily a must have, since we use other tools as well that already do this
• Integrated Levels and Curves tools, as well as Gamma mapping, this is a MUST HAVE
• Integrated LUT support (most popular formats, 1D and 3D LUTs are a must - GPU accelerated!)
• FAST! I cannot stress this enough. The viewer must be snappy. No lags, no chuckles, no stutters, it has to be lighting fast to work with
• Simple UI. It has to be lucid (synoptical)
• Support for basic compositing is nice, but definitely not a must have
• Same goes for support for masking

In a production facility, my approach would be to take RV and integrate Corona into it. It'd be much much easier than writing my own viewer and the features would far exceed what I could ever do on my own. That's just a suggestion.

But generally, the last screenshot here... it's just ugly. Huge buttons with text, round corners, shadows etc... this is kindergarten "artwork", not a production ready tool.