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

Pages: [1] 2 3 ... 131
1
It does not change the default quiet mode settings. Instead, you are offered an option in the file menu to open a scene without popups. Any popups. Including missing assets and others that might tell you that something's wrong with a scene, for example missing plugins. That's why I'd not activate it generally.

Opening a scene with the menu item turns on quiet mode, loads a scene and then switches it off again. This is perfect for "known scenes" you work on and to avoid clicking away xref objects scaling confirmations and similar "yes-I-know"s.


Good Luck




2
Hi,

I would never turn on quiet mode generally (as the snipped does). You will miss important notifications sooner or later.

Maybe this one is interesting for you:

https://forum.corona-renderer.com/index.php?topic=33381.msg186113#msg186113
(if you are on Max 2025: I have an updated script supporting the new menu system of Max but have not shared it yet)

In that thread it turned out btw. that you cannot create CoronaBitmaps when quiet mode is active. A glitch still present in Corona 12.1 (and not even logged afaik).

Finally:

they're usual false positives anyway seeing as it doesn't like loading Corona pre-set materials for some reason.

Are you able to provide an example for this? I never had something like false positives when it comes to the missing asset message.



Good Luck





3
[Max] Bug Reporting / Re: Crashing with Vray materials
« on: 2024-10-02, 07:52:21 »
it completely removed all the views and SME become unusable, apparently there's no way to add new views, when all of them are deleted.

I think you are just not aware of where to do this?


Good Luck



4
[Max] Bug Reporting / Re: Crashing with Vray materials
« on: 2024-10-01, 22:39:56 »
Hi,

BTW, if anyone knows if it's possible to close all slate material editor views without opening SME itself

try

Code: [Select]
while sme.getNumviews()!=0 do sme.deleteView 1 false
But sme has to be initialized, it does not work if you are loading a scene by doubleclick or "open with". So

- start max, open sme, close sme
- load the affected scene
- run the line above


Good Luck




5
Please stay on topic people, this thread is for discussing issues related to Corona 13 daily builds.

All IS about v13. The fact that a v13 daily got v12.1 (the usual procedure) does not change the fact, that things are suggested here to be "ok" for v13. Nobody mentioned that any change is a temporary solution (cure the disease by killing the patient - see Francis Bacon) because there are issues. It is rather presented as a "fix" and I never ever want to have this "fix" in 12.1 nor in v13.


Good Luck




6
[Max] I need help! / Re: Help with faking a lighting effect
« on: 2024-08-16, 16:33:32 »
Decals are not perfect, as they just project texture/light, they are not blocked by geometry.

Sure, but your example shows how powerful they are, even in situations where you do not think of them immediately. And if there would be some geo "blocking" them, it would just receive the decal as well, looking correctly.


Good Luck




7
[Max] I need help! / Re: Help with faking a lighting effect
« on: 2024-08-16, 15:30:49 »
Self-illu will be much slower and will not be able to cast a sharp shadow, especially from such a distance.

I'm silent once you try and get the same thing OP is after ;)
Then again, maybe I'm just wrong.

It must be me that everyone gets me wrong lately :) I just had the feeling, what Aram wrote was not clear enough to you, sorry.

The rest was about the option Aram suggested (using a decal with light material): It may be slow because of what I wrote - it turns the entire object into a light and Corona has to handle it.

So I thought that using a material just with self illumination for the decal would work as well to avoid this. And switching to self illu in the scene now shows in fact almost the same effect, but without creating that amount of light groups and thus is faster (just switch the CoronaSelectMaterial).

Basically, as mentioned, I would try with multiple lights as you. But because of:

How would you recreate the effect without modeling/shading the reality of the environment that's creating it?

...my variant is disqualified because I have 3D-blinds in the scene :) But this is the result. I used your scene @Aram, I hope you don't mind. The advantage may be that you can control sharpness by the light size (while adjusting intensity) and playing around with directionallity offers some interesting effects. And it's the most performant option while rendering.


Good Luck





8
[Max] I need help! / Re: Help with faking a lighting effect
« on: 2024-08-15, 15:26:03 »
You need to produce different lighting directions where light is oriented slightly differently, that won't work with a texture from a single point.

I think Aram just would create a simple 2d texture that looks like the effect of multiple lights and use that as decal with light material.

But if using a CoronaLightMtl for decals, it turns all triangles of the mesh on which it is projected into a light emitting primitive. Maybe self-illu would be enough for trying this option.

I'd personally go for multiple lights with slightly different locations and intensity through the window anyway.


Good Luck




9
And they most definately don't want to have to change all or part of their workflow mid job just to be able to achieve the same thing they were achieving previously

At any time, kick legacy stuff if outdated or designed newly and properly. But what is happening here is pure activism, destroying (again) a working and useful feature.


Good Luck




10
The discussion involved the devs, support, and QA.

"The article mentions how important user feedback is, so here’s how you can become part of the process!

So where is the user here? There has not even been a daily containing those changes, it just has been released in a final hotfix version with no chance to discuss anything, not to mention testing.

- Saying "this feature is a broken mystery" will help literally nobody. You should instead explain what exactly is wrong and how we can improve it.

I'd say instead, quoting a single expression without context won't help.

If you read 1) and 2) it should be clear. VFB history is an interactive feature and it got crippled because of some situation that may occur if users brain is in idle state. I already mentioned, that disabling history autosave in slave mode of course is something that should have been there out of the box. But why those master and sequence restrictions? No one would render a complete animation having history autosave activated. If so, it is just a user error, nothing more. Corona does not check dozens of other user errors like that (worse ones that should be handled at Corona side included). But in this case it does, while obscuring the feature at the same time.

And exactly right now I use that feature in Corona 11: the client has chosen a few shots and I render those frames into history because there will be some changes. And I need the current state for later comparison. And yes, it's a frame sequence (with disabled output). And yes, I have some DR nodes active to speed things up. The use case is to use the feature, that's it.

The obvious solution for me would have been to check at render start if 1. VFB history is enabled and 2. if a sequence is going to render and if so, to issue a warning when starting to render. This should be enough to solve that issue (if it even is one) without restricting a feature that has been working perfectly until now.

Finally about "mystery": try to make a lists of DR render on/off, iterative render, interactive render, frame sequence, single render where you would see the consequences of using VFB history autosave. And try to create a support article about it. And compare the result with the (former) philosophy of Corona.


Good Luck




11
Quote from tooltip "Render History and A/B Comparison":

Quote
"If enabled, a new item will be automatically added to the render history in the Corona VFB after each render ends (both IR and Production). This feature is automatically disabled when rendering sequences, and also for nodes during distributed rendering."

This is another feature Corona team managed to turn into some broken mystery, needing a diagram to look at when trying to use it. And it feels like decisions are made to work around design flaws rather than solving the issue itself.

1. IR results have never ever been saved to history in any Corona version so far. It was even considered as a bug in some daily when it happens - I remember reporting this, and some famous developer who is unfortunately out of duty atm. confirmed it as a bug. If (this==kindof NewFeature): the result does not get saved into history by pressing "stop" if using IR which is the "stop and save the results so far" button in contrast to "cancel", so it SHOULD be saved in history when pressing "Stop". It only gets saved if IR "Max passes" is set explicitly by the user - and has been reached.

AND it only happens if having "Time Output" to "Single"?! Who on earth should be able to understand and remember all this? If I just want to IR a frame and would like to have a history item from it, I have to change my scene setup, really? Btw: IR stop condition still defaults to 0, meaning "rendering forever", so you usually do not get a history item using IR anyway (a shame to have it at 0 by default nowadays btw.).

2. Do not even try to be smarter as the user. If I render a sequence, say frame 0 to 20, every 5th frame, I want to have exactly this in the history if I have enabled "autosave" - independently of having DR activated or not. DR on/off should never ever make any difference while using any feature anyway. Of course DR slaves should not write history items locally, they should never EVER write anything to production files. I've been fighting a lot to just have slaves not to overwrite light cache files - hard to believe that it took almost a decade to get that destructive behavior removed. Slaves should just deliver data to the master and never touch any production file, no need to stress that in a tooltip.


Good Luck





12
[Max] Daily Builds / Re: New VFB Skin and functionality
« on: 2024-08-05, 09:19:48 »
Hello, is there possible back smile from legacy?

Not by using this script, sorry.


Good Luck




13
A workaround what for?


Good Luck



14
Tested quickly a 11k JPG, my findings:

Difference between 8k and 16k settings for "Bitmaps" using 3ds Max bitmap: None

Difference between 8k and 16k settings for "Procedural maps" using Corona bitmap: Very noticeable

So it looks to me as if the 3ds Max bitmap node is limited to those 8k you mentioned (?). Corona bitmap seems to go higher (and generally looks better in the viewport anyway). But as you said, could be filtering only.


Good Luck



15
Perhaps this is a shortcoming of max rather than corona?

Well, vray obviously can do it. The Max restriction is just the maximum size of 16k afaik.

Can you explain the difference please for general knowledge purposes.

Not sure what you mean here, it's just as documented here. I cannot tell you why CoronaBitmaps are treated like procedural maps, could only guess :)

Good Luck



Pages: [1] 2 3 ... 131