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

Pages: [1] 2 3 ... 6
[Max] General Discussion / Increasing slowdown of UI
« on: 2018-03-21, 20:05:22 »
While discussion some of the slowness of the UI in Max on FB I've ran into an interesting observation:

Code: [Select]
print (renderers.current)
for i= 1 to 5 do
( renderSceneDialog.close()
print ("dialog time to open: " + (timeStamp() - t ) as string)

This piece of mxs times the amount of time it takes to open the render dialog..

Time recordings below, in short it shows that scanline and V-Ray have a constant open/close time.. while Corona get slower and slower at each open/close cycle.   That slowness sticks even when switching back to another renderer.

Tested on Max 2018.4, Windows 10, GTX1080.

Corona version: 1.7 (hotfix 3)
Full-speed, Non-debug, MaxSDK 2018
Build timestamp: Feb  8 2018 13:09:21
Defines: Wide RGB


"dialog time to open: 476"
"dialog time to open: 447"
"dialog time to open: 449"
"dialog time to open: 446"
"dialog time to open: 452"
"dialog time to open: 448"
"dialog time to open: 441"
"dialog time to open: 438"
"dialog time to open: 474"
"dialog time to open: 446"
"dialog time to open: 470"
"dialog time to open: 443"
"dialog time to open: 458"
"dialog time to open: 459"
"dialog time to open: 453"

Scanline: stable

"dialog time to open: 364"
"dialog time to open: 339"
"dialog time to open: 323"
"dialog time to open: 325"
"dialog time to open: 331"
"dialog time to open: 327"
"dialog time to open: 326"
"dialog time to open: 328"
"dialog time to open: 346"
"dialog time to open: 324"
"dialog time to open: 343"
"dialog time to open: 329"
"dialog time to open: 324"
"dialog time to open: 325"
"dialog time to open: 325"

V-Ray: stable

"dialog time to open: 1134"  <------------------------------------------------------ normal
"dialog time to open: 1253"
"dialog time to open: 1371"
"dialog time to open: 1476"
"dialog time to open: 1619"

"dialog time to open: 1630"
"dialog time to open: 1727"
"dialog time to open: 1818"
"dialog time to open: 1954"
"dialog time to open: 2113"    <------------------------------------------------------- slow

Corona: Delay

Then scanline again.. stable but a lot slower then first run:

"dialog time to open: 959"
"dialog time to open: 940"
"dialog time to open: 956"
"dialog time to open: 949"
"dialog time to open: 1036"
"dialog time to open: 958"
"dialog time to open: 957"
"dialog time to open: 985"
"dialog time to open: 948"
"dialog time to open: 944"


[Max] Daily Builds / Re: Daily builds version 2
« on: 2018-02-05, 15:44:13 »
Just had a quick go at trying out the volumetrics, the rendering speed is already quite nice! I created a burning object using PFD and pressed render and that just worked fine :)

Some things that stood out, most of the WIP I guess:
-Ability to be lit seems to be missing, it's lighting the scene but I can't light the smoke with corona lights.
-interactive render doesn't pickup many of the scene changes yet (time scrubbing, volumetric rendering settings  etc).
-alpha seems to be always 100% transparent
-And a grid of omni lights appears during inter active rendering, I think those should be hidden/out of view.

I notice that for the look and feel of the rendering Corona is using PFD's volumetric settings, will it eventually get some sort of corona-native way of doing that for generic (openVDB) volumes?  They can have arbitrary named grid and such that need to be mapped to various shader properties, ideally using curves and gradients etc.

Anyways, great work and exciting to see all this taking shape!

edit: Very nice to see DOF working on this as well!

[Max] Daily Builds / Re: Daily builds version 2
« on: 2018-02-05, 09:09:35 »
another one :)

[Max] Daily Builds / Re: Daily builds version 2
« on: 2018-02-04, 10:36:00 »
Just to encourage openVDB support I'm working on a nice Houdini doodle that does some funky stuff to the corona logo :)  I'll pimp it up a bit more and render it with Corona once it's capable of it :)

Awesome! :)

In both you can plug your self illuminated material into a rayswitch material (direct visibility, reflections, refractions), and plug a different material (e.g. grey or black) into the GI slot. Checkbox would be a faster solution, but I am not really sure if we need it as it would be one more item in the UI.

Ahh yes, that should work too. Forget the checkbox.

I'm aware of that, but sometimes I need objects in an animation to be highlighted for example.  It's easy to render out a mask and raise levels in post, until it goes behind glass or something. For things like that you want the full material + self illumination but without emitting actual lights.

Lots of times I now use the LightMtl to render objects with baked textures for example, put the texture in the light material and disable emission and you have a nice way to render texture as they are without being affected by any lights. But let's say you do want some reflections on it you can't do that easily. You have to do the same trick with a normal material which will always emit actual light. .

So that's why I asked for that checkbox.

The LightMtl has a 'emit light' toggle which is quite handy in certain situations where you want something to be self illuminated but not add the the overall light contribution.

Would be nice to have that option for the self illumination property op the normal corona materials as well.

Off-Topic / Intel 5..30% slowdown due to security bug fix..
« on: 2018-01-03, 10:26:35 »
Might be a good idea to benchmark some before/after patch  statistics:

[Max] Resolved Feature Requests / Re: Focus Pick Option?
« on: 2017-12-01, 00:08:13 »

I've got a script called 'proFocus' that does this by simply clicking in the viewport. Supports CoronaCam as well.

[Max] Resolved Feature Requests / 'hologram' shader
« on: 2017-11-24, 10:07:09 »
I'll just leave this here..  something like this would be great to add some depth to large medium distance buildings..

Is something like this technically possible for an engine like Corona?

I made that setup following the explanation in the article linked in my first post. But if it's indeed not correct that sort of proves my point doesn't it :) 

Maybe one of the render developers can have a go at it and create a basic material setup that is technically correct and yields correct result.

[Max] Daily Builds / Re: Daily builds version 2
« on: 2017-11-03, 11:30:29 »
Technically maybe not but for all intents and purposes they still load their external content and you can instance them as well keeping a low memory footprint.

But I'm using them mostly to read alembic meshes generated in Houdini into max, for that it works just fine.

any reason you are not using max's own alembic reader for this? you should have no reason to add vray to the equation I would think.

Quite a few actually.  Main one being the Max is locking the alembic file so you can't externally update it when it's used in an open Max scene. Even when you delete the object it doesn't unlock. The controller setup is a bit whack. You have to apply an abc controller and load the alembic file in there as well. And a quite a few other small small bugs and issues.

I'm the main dev that worked on SideKick ( ), an interactive bridge between Max and Houdini and I getting it to work properly with Max's native alembic loader was a nightmare. Vray's proxy loader just worked fine and has quite a few more options as well.


I might be wrong but isn't that why .sbsar files were introduced? There is a Substance engine bridge that lets you open Substance files directly and if you've set them up correctly in SP / SD it should translate over... I haven't tested it too much because of the reasons from my first post but...

They are handling the integration themselves now, much better. The plugin linked to in the forum supports all the latest sbar files.,14223.0.html

But sbar gives the same problem as substance painter. They basically both output a bunch bitmaps. One thought the sbar loader/engine and the other simply using baked out bitmaps. And sbar being even worse since they are not always setup to be compatible with Corona directly requiring even more hassle.  ( metal/rough vs spec/gloss)

It's not simply plugin in a few maps into to a corona material, see attached image. And some bitmaps need gamma=1 others 2.2 etc..  Sure it's not rocket science when you know the trick and use a template in a material lib but having a dozen of these materials in a scene makes it hard to manage. Part of that is to blame on the SME itself because it can't make nested networks so there is no way of hiding parts out of view.

I had to write a few scripts to manage all the bitmaps. Applying a different texture set, or a new one, involves updating 5 bitmaps and maybe fine tune a few parameters.. mind numbing.

Not sure what a good solution might be but ideally I'd just like to get what I'm seeing in substance painter into the VFB without all this.  Just point something to a folder that holds the bitmaps and be done with it. When you want to have full control you can always set it up manually like the screenshot, but 99% of the time I'd be happy just to simply get it as it looks in substance painter.

Pages: [1] 2 3 ... 6