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

Pages: 1 2 [3] 4 5 ... 125
31
Gallery / Re: Earth without post-processing
« on: 2024-03-15, 17:04:10 »
Looks great. You've probably compared your renders to countless images of the real thing but one thing that sticks out for me is that land/forest appears too reflective. It might be the volumetric effect of the light scattering in the atmosphere but to me it looks like there's too little difference between sea/land reflectivity.
Some examples:
https://images.t3n.de/news/wp-content/uploads/2023/01/iss_suedostasien_erde_weltall.jpeg?class=structuredData-medium
https://www.woodtv.com/wp-content/uploads/sites/51/2024/02/NASA-MICHIGAN-MITTEN.jpg

Of course it all depends on the light source angle and I might be comparing apples to oranges but I'd expect landmass to be way rougher and less reflective or the sea to be more reflective.
Another thing looking slightly off is that the landmass colors seem to be slightly too saturated.

Still, good job overall, the blue hue of the atmosphere looks great and that one is really tough to get right.

32
I'm not sure but 2023/2024 might have added an option to suppress warnings/errors on startup or scene loading to prevent problems like this one. You might find something in the Max docs - again, not sure but I seem to remember there was something done about this in one of the recent versions.

33
Meanwhile, the workarounds include either extruding the spline or using 3ds Max features such as the shape map or conforming geometry (which may or may not work...).
Wait, last time I checked the built in Shape Map only worked with a few primitive shapes like rectangle and circle but would not accept arbitrary shapes - has this changed?
Also, it always produced jagged results, its borders/results were noisy and never clean enough for me to bother using it.

34
I guess this is a problem on the max side of things rather than Corona, especially if both of you are on 2024 (at least one of you are) and there were changes to the Python version used that for some reason blows up. When you google for the error it's obvious it's some Python module that throws it. I'd report this to Autodesk...

35
EDIT - removed since it was probably not a good idea to expose someone to unsolicited emails. Sorry.

36
As far as I know the info displayed is not actually only scene/geometry parsing but also other things like like loading of maps, so it might be that your new PC is slower at loading maps from disk or through network. These are also single threaded so you may have a mix of different reasons - single thread speed of your new CPU might be slower than of the CPU of the old machine, disk/network access speed, and your new CPU might suffer from under-utilization of CPU threads (where only half of the threads are working on a task etc).

I'd look into other means of benchmarking (not 3dsmax) to measure different tasks (CPU single threaded vs multi-threaded, RAM speed, disk/network I/O) and compare how each of the PCs performs. This will probably give you a better picture of what exactly is different between the two PCs.

37
I have no idea how Scan Mtl works but maybe they need correct face normal orientation due to the nature of the data (it comes with captured normal info)? In other words, could it be that normals are flipped on that geometry...?

38
[Max] I need help! / Re: VR 8k issue
« on: 2024-02-27, 17:16:36 »
I guess you could just increase render size in steps and see where it 'breaks' and what RAM consumption looks like when it happens.
I've rendered out bigger spherical images with 64GB RAM so most likely yes, it is RAM and 30/32GB probably means it's at the limit. When this happens you should also see the OS becoming slow to work with, freezing for a few seconds etc.

39
...
Edit: Specifically how to remove this clear reflection without using roughness. see attached.
EDIT 2: And without using fake anisotrophy
Yeah that area is not looking good, same for the harsh reflection/highlight cutoff on the right box. What would be needed to get rid of these?
At least similar fireflies are there in Fstorm too, these would be my main concern in both renderers, wonder if they'd clean up without clamping highlights.

40
[Max] Daily Builds / Re: New VFB Skin and functionality
« on: 2024-02-20, 14:27:20 »
If I had a wish, for me it's how the denoiser workflow is implemented:
1. Let us denoise *during* a final render, with whatever the denoiser is set to. I'd love to see if the noise level is good enough while i'm rendering. Sometimes I'll set way too many passes and having a way to preview the denoiser without stopping/cancelling the render would be great.
2. Currently, a denoised render will save to the history only if it was a final render, IR will save to history without the denoiser... This is inconsistent and makes it impossible to compare IR vs final renders since you can't save/view the denoised version from IR.
3. Denoiser checkbox in the VFB is inconsistent - for final rendering it will work only after a render is stopped/finished. For IR it can't be disabled without re-rendering (and has no function there), plus, it has to be disabled in a different place. It just doesn't do what it implies the way it's designed now.

For me it's the small things and consistency between final/IR rendering is not where it should/could be wrt to denoising.

41
1) Is it possibile to link and hdri image to a camera so that when you rotate the camera the environment follows?

Corona bitmap allows you to link environment rotation to arbitrary object's transform.
Yeah totally forgot about that - true, way easier than wiring parameters.

42
Thank you! I will check every step! This is the HDRI that I am using: https://polyhaven.com/a/sunset_jhbcentral 

As you can see, also in the attached screenshot, it is quite difficult to understand if the height of the camera was 1.8 m or 2m for example.

And I have other 2 questios. I didn't find solution yet on this forum. (Do I have to create a new thread?)

1) Is it possibile to link and hdri image to a camera so that when you rotate the camera the environment follows?

2) If i change camera's focal lenght  the hdri changes automatically. Is there a way to detach this connection? That would be stupid? Thank you!

1.8m or 2m - with a value range so narrow it will probably be impossible to tell without knowing some dimensions in the HDRI, for example the distance between the tile borders or those cylindrical whatever-they-are. Also, I'm not sure the roof in that HDRI is level, if it isn't this introduces another level of uncertainty.

1. I guess it should be possible with parameter wiring, where you'd wire the HDRI's U offset to camera Z rotation. But I'm not sure this will help as parameter wiring in Max tends to be slow and with the texture being recalculated whenever you rotate/change the camera it might be too slow to work interactively.
2. Yes, this is correct and expected. If you think about it, changing the FOV should of course show less of more of the world surrounding you. I don't think you can expect this to work independently without creating other problems - for example you could change the scaling of the U/V parameters of the HDRI but this will cause problems where the HDRI wraps around, the seams wouldn't match anymore. Plus, you're likely to see that something's not right.

43
I wonder if offering numeric inputs wouldn't be good, along with a color swatch so you can either enter RGB values in 0-255 OR click the swatch to open the color picker and input there as you would now, whatever is more convenient to the user. So basically offer the same input for LDR values as you do for HDR linear.

Opening the picker, assigning the correct color space, choosing the color, pressing OK and still having to use the dropdown is quite a lot of mouse clicks for a single color assignment. I totally get why OP feels this is a bit too much for such a simple thing.

44
For outdoor HDRIs, the horizon line will be at the vertical center probably for all HDRs that you come across, unless the panorama was taken really high up which is improbable.
For indoor HDRIs, dome mapping really makes sense since light sources and objects will be closer to the camera and will make a difference when rendered from the correct vs incorrect height. Even using a wrong camera height can be interesting sometimes.
Dome mapping is preferable too when you render an object on a surface that uses the HDRIs projection on the ground with a shadow catcher for example . Anything close to the surface will look definitely better as there's quite some difference between how the surroundings look to an object at 0.1m vs 1.6m.

In order to determine a somewhat correct height at which the cam was placed you'll need to know the physical scale of a feature visible the pano, best one that's on the ground. It can be anything like street markings, a tile, a curb, something that you know to some certainty, the bigger the object/feature the better.
Create a plane at 0/0/0 big enough to cover the ground of your HDRI and assign to it an UVW modifier in spherical mode.
Create a material for the plane, assign the HDRI in question to it and display it in the viewport.

Once you have the plane display the HDRI on it, you can move the UVW mod's gizmo up/down and see how the projection/mapping of the HDRI on the plane changes. You might have to increase the plane's tesselation for a better result in the viewport.
Now create an object similar in size to the feature in the HDRI and place it somewhere where the feature is projected on the plane. If you move the gizmo and the feature projected/displayed on the plane and the object you created match in size then read what the Z value for the UVW mod's gizmo says - that's roughly the height the pano was taken at.

I'm saying 'roughly' because the method is not accurate. Accuracy will improve with increasing size of the feature though, that's why it's important not to use small objects as features. It will also work only somewhat reliably on the things that are on the ground closer to the camera. The farther the object from the camera the more it gets distorted when projected on the plane, making it hard to determine the correct height.

Still, this method can work surprisingly well since it 'maps' the surroundings on a plane and helps to get an idea of its physical scale. Once you have some other 3d geometry in the scene to compare the projected HDRI's feature to, you quickly see whether the scale (or better projection center / UVW mod's gizmo) is far off or not.

Note - I'm not in front of the PC right now so can't check - I've done this a lot in the past but can't remember if I used camera projection or spherical projection from a UVW modifier on the plane. I know one of these methods had an advantage because it works better in the viewports. If the above method doesnt work for you, let me know so I can check.

45
[Max] Feature Requests / Re: Faster Rendering
« on: 2024-02-06, 15:17:40 »
This is something that would probably be a nightmare to solve w.r.t. UI/UX but it's actually a useful thing to have. Let's say Corona would have a dedicated material for this where you can override any slot/value with a single one across all materials, but keep other material properties.
Brazil r/s had something like this. The concept was you would use a special material and everything you'd want to stay would get a special pass-through map (meaning it wouldn't be changed und using the object's material properties in that place > it would pass through and not be replaced) but everything you assign a map to would use that map instead. Hard to explain but it was designed to work well with minimal setup work/time.

Pages: 1 2 [3] 4 5 ... 125