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

Pages: [1] 2 3 ... 20
1
Hi, why are you suggesting to add these settings to the VFB? If I understand the original suggestion, you'd like to have some settings shared by multiple cameras. Wouldn't it be better to introduce some kind of "take settings from another camera" option, similar to what we have implemented for the ColorCorrect texture? That way you would not have to switch the postprocessing settings in VFB at all whenever you switch the cameras.

2
Resolved feature requests / Re: Memory usage breakdown?
« on: 2019-07-12, 05:47:51 »
Yes, that is already on our TODO list.

3
General Discussion / Re: Phoenix fd foam support
« on: 2019-06-27, 09:27:42 »
Unfortunately phoenix foam is still not supported yet

4
Feature requests / Re: Best viewing for rendernodes
« on: 2019-06-13, 10:28:40 »
You have way too many nodes :) When seeing all this together, is it important for you to see all the details of all nodes? I'm thinking that it might be better to be able to collapse the node entries, so they'll still be displayed in a single column, but each entry will take less vertical space. If we were to implement this, what is the most important info for you that should be visible even in the collapsed state?

5
Feature requests / Re: To go further with "Set Focus"
« on: 2019-06-12, 16:13:31 »
In that case it's already better ;) The focus picker uses the exact point on the object you clicked, not its pivot.

6
Thanks for reporting this. Fixed for v4 RC4

7
General Discussion / Re: CXR Autosave
« on: 2019-03-28, 17:05:35 »
In the autosave file name pattern you can use a subset of "tags" which are used in the render stamp. In the system settings dialog (the one you use to configure autosave) you can click the "?" button next to the VFB title setup to see all the available tags. Some of these are not available for autosave (like the rays/sec metric), but you can use %f which will be replaced by the filename of current scene.

8
Feature requests / Re: Lightmix should correspond accurately
« on: 2019-01-04, 14:08:41 »
Your suggestion is perfectly valid as long as there is just a single light allowed per LightSelect element. "Unfortunately" we allow multiple lights to be assigned to single element and then this wouldn't really work unless all of the lights have the same color.

9
This should be fixed in today's daily build. Could you please just confirm that your problem is indeed fixed, so that we can close this thread?

10
Bug Reporting / Re: Light Lister doesn't show Sun
« on: 2018-11-25, 08:26:04 »
Yes, we know about that. It's one of the limitations of current implementation. We'll be expanding the lister in v4, adding sun & light material to light lister as well as other object type to the lister (cameras & proxys, maybe some others).

We'll leave this thread open for a few days as I guess others might view this as a bug as well and want to report it, then we'll move this thread to resolved. In the meantime, if you have any other suggestions on how to expand the lister, please note them in the feature requests section.

11
Thank you for the answer! If i understand correctly, given the same image dimension and bit depth, the only thing that matters, is number of channels? So 1024x1024 8 bit texture will take 1 MB RAM if it's greyscale, 3 times as much if it's RGB and 4 times as much if it's RGBA?

Yes, that's correct.

Also, what is the better option - to have 3 single channel textures, or 1 RGB texture, in terms of RAM consumption, scene parsing time?

Good question. I never tried to measure it, but as long as we're talking about 3 files vs 1 file, there should not be any noticeable difference in memory consumption or parsing time. When we get to 3000 vs 1000, the difference might be a bit more noticeable in terms of parsing time as there is some small overhead with opening each file, etc.

The overhead is much higher when the texture files are stored in a network location, as there are higher latencies involved in opening the individual files, etc.

So, I would definitely not worry about this unless you have problems with the parsing times and have a reason to suspect that the texture loading might be the cause of those problems.

One of the key points of Corona philosophy has always been that users should not worry about technical details. So if you ever get to the point where 3 files vs 1 makes any noticeable difference, I would prefer to solve this by optimizing the texture loading code rather than forcing the users to store their assets in a certain way.

12
Corona stores the images in memory uncompressed, so this really depends on resolution and bit depth. An 8-bit 1024x1024 JPEG will take exactly the same amount of memory as an 8-bit 1024x1024 TIFF no matter what's their size on disk.

13
General Discussion / Re: Corona + Nvidia AI Denoising
« on: 2018-11-13, 08:24:00 »
Yes, just switch the denoising mode to "Fast preview (NVIDIA)"

14
Feature requests / Re: The most wanted feature?
« on: 2018-10-16, 13:57:48 »
Well, autobump is also already implemented, but the other displacement improvements are still valid.

15
Feature requests / Re: Corona Materials Library Resolution
« on: 2018-09-26, 09:41:00 »
This will apply to all textures loaded by Corona.

Pages: [1] 2 3 ... 20