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 - loocas

Pages: 1 2 [3] 4 5 6
31
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!

32
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!

33
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.

34
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.

35
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.

36
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.

37
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.

38
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.

39
General Discussion / Re: How should the frame buffer look?
« on: 2013-01-19, 12:52:36 »
I'm sorry to say, but this is a prime example of a horrible UI design.

You don't take into account anything from 3ds Max, so, basically, you're making the very same mistake Autodesk does with additional new features in Max, such as the Ribbon etc...

There is no consistency, no history, no legacy.

The UI is ugly, out of place and looks like designed by a software programmer, not a UI or UX designer.

Besides, one of the most brilliant VFBs, or actually viewers, can be found in Nuke and Fusion. A distant second close would be VRay's VFB.

Just my $0.02

40
Gallery / Re: Our first TVC done in Corona - Dr.Max
« on: 2012-11-14, 23:04:03 »
Ha! Very nice. 3h is quite a lot, no?

It is extremely long. And even after that, the interior was still noisy as fuck. :( So I had to de-noise it in Nuke and re-comp the interior back over the original.

Love it !

How did you manage to avoid  flickering? PT+hd cach with high samples ? can you share please your config

Nothing fancy about the config. :) But I did lobby Keymaster into implementing the temporal blending of the HD Cache. I pre-calced a single frame at very high settings and had that cache be blended during animation. Flicker free. :)

The noise was a different question, though.

I'm currently working on three other TVCs with Corona. One of them even more challenging than this one coz it'll have to be photo-real and perfect. Will share when done.

41
Gallery / Re: Our first TVC done in Corona - Dr.Max
« on: 2012-11-14, 22:30:27 »
O_O you really did it...

:D yeah.

42
Gallery / Our first TVC done in Corona - Dr.Max
« on: 2012-11-14, 21:09:36 »
I'd like to show you our first TV commercial done entirely in Corona.

This is exactly the type of a TVC that Corona is so good for. The pack-shots were super simle, super fast to render and comp.
The first opening shot was a bit of a problem, mainly due to noise. Corona took about 3 hours per frame for the first shot and I still had to de-noise the interior in Nuke afterwards.
Other than that, full motion blur and DOF done in-camera for the packshots. But DOF and MBlur done in post in the first shot for flexibility reasons.
Rendering everything in a few passes for more tweaking possibilities.

But, Corona is certainly usable for this type of stuff. The ad is currently on air in the Czech Republic.

Congrats, Keymaster! ;)

The full ad: http://prev.duber.cz/DrMax_FINAL

43
Feature requests / Re: Which 3D soft to integrate into next?
« on: 2012-11-04, 17:58:10 »
Considering the current state of Corona and who it's aimed at, I'd say modo makes most sense.

Competing with Arnold or PRMan on the Maya/Softimage battlefield will be extremely tough and without proper particle/volumetric rendering it'd be pointless, imho.

44
General Discussion / Re: Strange dot artefacts in renders
« on: 2012-10-18, 19:50:11 »
Its not alpha 3, right? Can you right-click them to see, if there is actually some super-bright color, or INF/NAN/IND?

Well, Corona says:

Quote from: Corona
Build timestamp: Mon Oct  8 21:14:03 2012 (ALPHA v3)
Max version: 2013

And the pixels are actually not even super bright, just bright.

45
General Discussion / Strange dot artefacts in renders
« on: 2012-10-18, 19:08:03 »
I tried rendering my test car scene in the latest Corona build I have (a week old, +/-), but I'm getting these strange super bright pixels in some places.

This render took 20 minutes (as before with the older build), illuminated only by the Corona Sky and Corona Sun.

Any idea where these might be coming from?

Pages: 1 2 [3] 4 5 6