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

Pages: 1 2 3 [4] 5 6 ... 111
46
Just a tip:

If you can use one of the Sini tools called Sini Forensic, it can help you scan your scene and provide you with an overview of problematic issues present in your scene.

https://sinisoftware.com/Plugins/Forensic

Yeah thats my first step every time and the file isnt showing anything problematic.

Is there any way to set up any of the corona passes to highlight complex materials?
Would be super useful to be able to do like a false-colour pass to identify shaders causing slowdowns.

47
Hardware / Re: Computer spec 7950X with 192 of RAM?
« on: 2023-05-05, 01:13:02 »
Exactly! My current "mobile-PC" I built is based on Cerberus-X which houses ATX board since I needed 4-DIMMs. Technically I could have used m-ATX but almost none exist and 99perc. of SFFPC cases are Mini-ITX or few ATX/E-ATX ones.

With 2 DIMMs, those Mini-ITX SFFPC cases are finally doable even for professional mobile workstation. Ideally the flat&thin "console" style (like Fractal Ridge) since those are easier to put into backpack, rather than the "Sandwich" ones which are smaller but thick like a brick. But cooling is still a bit issue for CPU there.

The thing is, the laptops are very close in performance to these PCs now, just 5 times louder :- ). But still much more practical for travel. (though not for dollar value and upgradeability).

Ive been tempted a few times by a workstation laptop but i like the idea of upgradeability or at least being able to potentially take parts from my main workstation like GPU, RAM and storage, and put them into a portable PC.

48
One thing i have noticed though is that even when i hide the imported objects, the slow rendertime stays there.
If i dont import it, the scene renders fine.

What if you delete those objects instead of hiding them, does it affect render time in any way?

As i track down the cause, i will test this out.
The railclone tip above helped with the parsing but my UHD Cache is still multiple minutes long so ive got some digging to do.

49
Hardware / Re: Computer spec 7950X with 192 of RAM?
« on: 2023-05-04, 17:42:50 »
even small 2-dimm ITX boards can now have 96GB ram. So let us know how it goes.

well damn i hadnt even considered this!
Small form factor travel-ready render PC can be a reality!

50
In general, hide half the objects and render. Still slow? Hide half again and repeat. If faster on the first halving, switch which half is hidden and continue as before. This should identify objects or materials, and once you pin it down, you can investigate why.

You could use material overrides too, usually worth enabling that globally and see if magically everything gets faster as then you're most likely looking for a problem material. You can still likely track it down with the steps above (probably easier than using exclusions to the material override).

Material override isnt something ive considered before so thats a good one to try early on thanks Tom.

51
Exactly what Tom said, or start a new empty scene, then start merging your objects one by one (or first half, then half of the remaining objects, and so on until the slowdown appears).

But since you mentioned the slowdown appears after merging a single object ("after merging an object from another file, rendering has slowed to a crawl") - then I guess that object is the culprit and the remaining part of the investigation is to figure out why it's slowing down.
Is that object related to some 3rd party plugin?
Is it using a complex material and/or a material using 3rd party plugins?

It could be a bit of column A and a bit of column B.
It has a railclone object in it thats gernerating lots of lights. However, the same number of lights when created manually doesnt cause the slowdown it would seem.
So i think it could be railclone, lights and material complexity coming together into a perfect storm.

I think ill put ijn some hours this evening and strip back the file.

One thing i have noticed though is that even when i hide the imported objects, the slow rendertime stays there.
If i dont import it, the scene renders fine.

52
[Max] I need help! / Tracking down the cause of a slowdown
« on: 2023-05-04, 16:34:51 »
Hi all,

I have a huge scene im working on and after merging an object from another file, rendering has slowed to a crawl with five minute parsing times 5 minute UHD cache times and rays/s under 200k.
I cant figure out what is causing the issue as the object im merging in, is fine when rendering in its original file and has no immediately obvious issues.

I was wondering if anyone had any tips and tricks they use for tracking down the causes of slow renders whether it be rogue objects or complex shaders.
If any of the devs have tips on what they do when assesing out scenes that would be really useful to know too!

53
[Max] General Discussion / Re: Taking a break
« on: 2023-04-19, 15:06:26 »
Good luck Ondra! See you around.

54

No news at present on what this initial implementation may look like, or even a guarantee it will happen (roadmaps are always tentative).

No worries,will keep my eyes peeled.

55
[Max] Daily Builds / Re: Corona Curvature Map playground!
« on: 2023-04-18, 13:37:28 »
Hello again,

I apologize if my second post in the same thread is considered flooding. I wanted to divide the issues into separate posts.

In this post, I want to discuss the missing flexibility of CoronaCurvature. It seems that its usage is currently limited.

For example, in my current project, I need to define convex edges and use them as a mask to generate metal damages and rusty effects.
However, when I apply CoronaCurvature, objects with edges near the front face and within the ray directionality radius start to display backedges on the front faces, causing issues.

This behavior is also observed in the official Corona tutorial, as can be seen here:
https://youtu.be/F95JyIaP5kQ?t=56
Jake presented a cabinet, and when he increased the maximum distance, inner edges began to pop up on the front faces.

Negative values in the "color spread" field do not solve the issue because we lose many convex edges.

It is also interesting to note that when I attach my geometry parts together, CoronaCurvature generates completely different results.

Please take a look at my attachments:

00.The official tutorial has issues too.jpg - screenshot from Jake's tutorial with the same issue.
01.Curvature-only.jpg - CoronaCurvature "sees" the edges that are behind.
03.Curvature-with-texture-plugged.jpg - the same situation with a texture plugged in.

I have also attached my test scene.

Currently, I have not found any way to solve this behavior.
Maybe someone has had the same situation and can recommend some workarounds?

Best regards


Just some quick thoughts on what could maybe provide a temporary fix.

Can this not be resolved by reducing your Max Distance and increasing your colour spread? If the max distance is larger than the gap between sides then i would assume it could have an effect like this.

Theres also the max data channel modifier that can do curvature maps in conjunction with a vertex color map as an alternative to corona. I find that its much slower to work with but could provide a solution to your specific problem.

56
I see that chaos cloud integration is on the roadmap for v10. Not expecting anything or planning a workload around it so dont worry. But im just curious as to what level of integration into the product it is intended to have and does it use the export scene function or will it still need to pull all of the textures and scene files, zip them up and repath the bitmaps etc?

57
Hi guys, as far as I understand, this is what you would like to request:

- a Corona-native feature (e.g. in a Corona Light)
- ability to apply a projector texture to a light
- the projector texture would not get blurred as it gets farther away from the light source, like with the "keep sharp pattern" option for IES (or this behavior could be optional so we could decide if we prefer blurring or always staying sharp)
- additionally, IES option would be still available and IES would interact with the projector (the projector mask would block the IES pattern)

The goal is to simulate a gobo effect, which currently would have to be simulated using glass lenses and caustics, which is not a viable workaround.

Is the above description more or less correct?

Hey Maru,

Just a slight correction on one point. The projector texture would ideally have a blur parameter so it can be focussed and defocussed. With gobos for things like mottled effects its often the case that the clients will want to defocus them to remove the harsh edges from whatever pattern theyre projecting. The images ive attached show the initial manufacturer gobo image, then a gobo blurred in photoshop and then assigned to a photometric light shining through a Corona folume fog material. Obviously without the IES masking. Ideally the blur would be driven by a parameter rather than needing to produce a different texture.

Other than that, yes the projector map should interact with the IES and block it. As far as i can tell, stage lighting IES represent the shape of the cone as defined by the lens that is fitted into the fixture rather than the shape of the light output at source. The light would have been masked by the gobo prior to hitting the lens.

It may also be useful to have left/right/top/bottom 'barn doors' which would just be straight lines to crop the light as required though this could be achieved with a texture applied in the map slot if necessary.

Due to the nature of how stage lights are constructed with the different lenses and with the light being masked prior to the cone being defined, the current method to achieve this in a physically correct manner would be to build an actual lens array which is of course impractical and insanely technical. Or to fake it with one of the numerous methods above but none of them allow you to mask the IES itself.

If you do ever get round to developing this, ROSCO are a major manufacturer of gobos and for my purposes i often image trace their product images in illustrator to get a higher res image. Source 4 are a stage lighting manufacturer and they provide all of their IES files for their fixtures. The series 3 being a major one in stage and theater. So the testing data would be there for you. I would also be more than happy to give feedback via the dailies if this ever makes its way there.

Thanks

58
And great results are possible with this current workflow :)

https://forum.corona-renderer.com/index.php?topic=39730

Cheers!

Yeah thats very cool and the renders look really nice but chances are the deliverables aren't the same as mine in this instance. Nor are they likely to be an accurate representation. They look like really great marketing visuals. What I'm looking to achieve from a design visualisation perspective is to show as accurate a representation of my clients specs as possible and because of the current limitations in all available lighting methods, thats not possible for a stage lighting setup. I don't see any gobos in those renders though that may be down to their design not including them. I just see volumetric rays and an IES.

59
• As the result/effect is a fake, there is no point to care about physically accurate units and intensities I believe. Of course it would be nice to mimic as close as possible the effect of a, say, 3000 lumen/lux light, but in CG it is almost always about making things looks nice than making things look like they have correct setup.

A gobo infront of a light is a real thing that happens in reality in basically every stage production. The result might be fake currently, but thats only because corona light implements it that way. Light shining through a mask still has an intensity associated with it. If you put in a black and white gobo mask, the light in the unmasked areas should still be the desired intensity. There absolutely is a point in using physical units for this.


"in CG it is almost always about making things looks nice than making things look like they have correct setup"


This is a fairly ignorant position to take from an employee of a rendering company that gained its success from physically based rendering without compromise. Ive been doing this for a decade and advocating for corona since beta 0.7 because of the fact that from day 1 it was focussed on accuracy and physically correct rendering and not tweaking dozens of settings to create fakes to make things 'look nice'. Looking nice in large parts of the industry is a by-product of being physically correct and photorealistic. They are not separate end goals. Why would you as a company be so concerned with keeping things physically based and 'unbiased' if you think that as CG artists we only want to make things "look nice". There are amazingly well known and talented artists out there who push their physically correct workflows to the nth degree with as few compromises as possible. The entire design visualisation process is about showing clients what the thing they're building/designing actually looks like as best you can. Not showing them an idealised version of what they want to see. If youre using CG as an iterative design tool as many of us do, then making things look correct rather than look nice is the ONLY requirement.

• Standard light with volume light effect and CoronaShadows does "filter GI rays" from the projection map. You need to have the light color set to white and the rays will be colored as the projection map, see the attached image.

This isnt what i was saying. The volume light effect being a post process effect provides no GI into the scene FROM the volume rays because it is not scattering light through an actual volume. Its not about making it a colour. I dont know where the "filter GI rays" quote is from but Its about getting that indirect lighting from the volumetric rays into the scene that actually light the atmospheric haze within the space.

So, remember that Corona is targeted for physically accurate rendering, while keeping things as fast as possible.
Projection functionality in Corona Light will bring what you want to achieve closer, but in fact push it further from usability, because impractically long render times because of volumetric material used with Corona Lights, which should produce ultimately volumetric effect, and little to no illumination.

The projection map feature may be a fake as it currently stands. But having a masked light via a gobo disc is very normal across all of stage and theater.

The issue that we face with the currently available workflows is that none of them are actually providing the features or level of control needed. With corona lights specifically, without producing the full 100% perfect glass lens setup, and using full caustics. We cannot currently do any gobo-based stage lighting setups in Corona because it doesnt allow for masking of the light shape + IES. Placing a plane with a texture on infront doesnt do this either. Its because of the lens array demonstrated in the diagram attached. Whilst applying a texmap and setting directionality to 1 does show a map if you put the light really close to a wall, i cant see a use for this feature in actually masking the light shape.

In reality, stage lights have a focal length at which the gobo filter is placed, and then a diverging lens corrects for the focal length which expands the light cone into the specific coverage we see in the IES (which is why the IES is so important in the process). If corona lights had a better implementation of the texmap whereby it actually fully masked the light at the source (which would make that feature immeasurably more useful) then this wouldn't be an issue that needs a separate slot and i think could be a great addition. As it stands, even with a texmap and 100
% directionality and no IES, the texmap is not focussed correctly.

Render times are only impractical if you aren't planning for them to be long. I know that if i want to show a client their lighting setup in the space they have designed with the desired level of atmospherics i will need to render for a long time and thats just part and parcel of the process.

Keeping the renderer as fast as possible is your job sure. What we do with it as users isn't really for you to worry about. Ive been using corona basically every working day for a decade and know at this point how long things take to render and I know that if I want to show proper volumetrics in a space I need to set aside far more time to render just like we all do for caustics. Not only that, but volumetrics aside theres still no workflow to project a gobo with physically correct intensity AND use an IES.


The compromise is acceptable I think - use standard lights with volume light effect, which (+) Render fast, (+) have GI rays from projection map, (-) unfortunately no IES support, but pretty neat hotbeam and falloff control, and (-+) with no physically accurate units, which are not quite needed.

Hard disagree im afraid. Not only is IES a major requirement for stage lighting (every manufacturer provides dozens of IES for basically every fixture because of the lenses they feature), Physically correct units are also needed because you need to limit lights to their spec sheet data so you know how bright it can be. It also does not allow for a lit volume haze in the space as would exist in reality.  As many others have requested over the last ten years, its a feature that would be very useful in stage and theater visualisations. The workaround isnt suitable for that use case at all and i dont think its your place to tell us as users what is and isnt needed in our workflows either.

TL:DR


To be able to create ANY masked light (Gobo) effect currently, there are no options that provide the full feature set required outside of building a full lens array with caustics. None of the available options provide the ability to use physical light units, a projection map (or gobo light filter) and an IES file together and none of the proposed 'compromises' address the actual feature request or provide the required end result. Putting a plane over a corona light with an assigned IES does not create the correct result because of the issue around the focal plane.

In an ideal scenario, the corona light would have the ability to apply a mask to the light that can be focussed and blurred independently and allow it to mask the projected IES shape. This would allow stage and theatre lighting to be correctly reproduced essentially across the board as well as other helpful workflow tools such as applying animated tree shadows or fake caustics.

See attached examples showing how a gobo light works and the exact effect that i think would be a great addition to the tools corona has to offer.




60
There's a volumetrics pass, but that's all volumetrics in one place and I think you are asking about those different volumetric objects appearing separately. But I think if you swap things around and use an INCLUDE list, then LightMix will do the trick - Corona Light only includes the volumetric object, then its LightMix will in effect be just that light's volumetric effects. If the light does have to illuminate other objects in the scene, you could duplicate it and have the duplicate exclude the volumetric object this time, then you have a LightSelect for the volumetrics only, and one for the non-volumetrics only. Not sure if that's what you're looking for though....

That's a very interesting workaround! I might give that one a try. Thanks Tom

Pages: 1 2 3 [4] 5 6 ... 111