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 ... 124
31
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.

32
[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.

33
Quote
@Aram
Not passing geometry to other tools in Max makes no sense, especially since you provide a way to convert Scatter instance to Max instances. Please just make sure it's passing its output internally, no need for additional scripts then.

I am not sure what you mean. What I was saying, is that e.g. array modifier is placing the geometry as-is, and it can be readily converted to editable mesh/poly. Scattering plugins on the other hand, place/show instances in the viewport, generate mesh on the render time, there is no readily available/interactive geometry to be converted. In fact, not even full mesh display scatter can be converted to editable poly. And when listening the maxscript when converting scatter geometry into max, it actually reads the data (transform) of the instances and creates the instances one by one. That is another reason why it can take very long times to do the conversions, not mentioning the display of high poly meshes in the viewport.

I think if a user needs/wants to convert a scatter object to a mesh he's probably aware of the mesh polycount, there is no need to 'protect' him from a wrong choice if the choice was a deliberate decision or needed for whatever reason in the first place.
If the mesh is shown in the viewport it already *exists* as a mesh, Corona is just not passing the data internally (Frood is hopefully proving me wrong with his script above, didn't test).

I guess the story went like this:
1. Corona develops a Scatter plugin, doesn't add passing geometry data internally because of either being overly protective (Scatter needs to be purchased/installed) or because no one thought of it.
2. Users request an option to convert to Max instances, it is added. Because of that, no one thinks passing geometry internally is needed anymore so it's left in that state.

We might have valid ideas and requests that are not making sense for developers/support. A user might have to hand out his scene to another studio that doesn't use Corona. Or I might want to convert all my Scatter objects because I know I'm going to have to re-render the scene in the coming years and I don't want to lose the scene's content to whatever the future holds for me as a cllient or Corona as a software/company. There are many reasons why I might want to use meshes or need them.

Also, not everyone has access to latest Max tools like Array - for example, I personally don't as I didn't go with the SAAS licensing for Max and am stuck with Max 2022.

34
Below my tests of different values...

int lights.envResolution = 1000 vs int lights.envResolution = 8000

Green = sun object, red = HDR image aligned to the sun.
Left is a circle shaped hole, right is a square shaped hole in the camera obscura's wall facing the lights.

35
I remembered I had a camera obscura test setup for it and tested now with the string option:

int lights.envResolution = {value}

And yes, it actually is the reason why HDR environment maps produce a 'pixelated' sun shape or shadows.
Setting it to 1000 - which I believe is the default value - will produce a square shaped sun in a camera obscura, setting it to the map's original resolution (8000 in my case) will produce a rounded shape.

Not really a bug but a side effect of Corona downsizing HDR images internally. This should probably be added to the online help with instructions how to use the string option.


36
Quote
Thanks but this.... didnt do anything, it created a new scatter object with same properties, no new meshes :(

Oh sorry, I assumed it must work since it works with anything else that produces/instances geometry procedurally. Seems Scatter was deliberately blocked from passing geometry to these methods in Max.

@Aram
Not passing geometry to other tools in Max makes no sense, especially since you provide a way to convert Scatter instance to Max instances. Please just make sure it's passing its output internally, no need for additional scripts then.

37
Hi there, I received some Models from a client where it has more than 200 scatters objects and I need to convert them to mesh, is there a way to convert them in batch or an easy way to do it, like I said, theres more than 200 scatters, its gonna take a lot of time to do this.

It will be great to have this operation in the Lister too.
Making a mesh snapshot is probably a fast way to do it (Choose the Scatter object you want to convert > Top Menu > Tools > Snapshot, choose Mesh), but it would not retain the individual instances, every Scatter object would become a mesh, not sure if that's what you're after. The advantage is that you can select all of the Scatter objects and when choosing Snapshot it will convert all of them in one go.

38
Small bug in Corona Decal.

In the object include/exclude.

If an object is included to receive the decal. Any object you link in a child/parent relationship to that object will also be included to receive the decal. Highly doubt this is an intended behavior.

Generally, this behavior has to be optional as it's found everywhere in Corona (for example in mask render elements). Please devs, make it an optional per-case thing, it's really problematic in scenes where you just can not change hierarchies, for example in animations. It's a nice feature if you really need it but a real headache if you don't.

39
I wondered if this has something to do with the fact that internally Corona downsizes a HDR quite drastically for lighting, basically resulting in the sun being a super bright pixel which would then display as a tiny square light source. Earlier tests might not have looked like this because this behavior might have been introduced at a later point.

40
I'm not sure but some include/exclude dialogs in Corona also include the hierarchy linked to a mesh. If your mesh is part of any hierarchy (is a parent or child) try to unlink it first and see if that helps. Might also be that the Railclone object that uses the path creates the dependency loop, in that case you'd need to copy it and use the copy as the distance object.

Also, if the path object uses the material the distance map is used in, that will throw an error too.

41
[C4D] I need help! / Re: Sun too big / intense
« on: 2024-01-18, 13:52:42 »
I believe the sun/sky intensity is modeled to be physically accurate, exposure at 0 EV is probably defined to be some sort of a typical camera time/f-stop/film sensitivity setting, hence the need to turn it down to not be over-exposed.
When you look at how bright the sun is versus an overcast sky versus a typical interior lighting it makes sense that it needs to be defined somewhere in the middle and that the default exposure will not be able to cover all cases and needs some adjusting.

42
[Max] I need help! / Re: Windows reflections exterior
« on: 2024-01-18, 13:02:11 »
Sorry for the confusion, the map slot names seem to have changed in more recent vserions, I'm still on v9, thanks for helping out Avi.

43
[Max] I need help! / Re: Windows reflections exterior
« on: 2024-01-18, 12:20:07 »
In the material properties, there's a long list of map slots available on the bottom, that's where you'll find these two slots.

44
[Max] I need help! / Re: Windows reflections exterior
« on: 2024-01-18, 11:10:29 »
Yes, you can use the HDRI you want to be reflected in the material's 'Reflect BG Override' slot that is used on the window objects. You might have to use the same map in 'Refract BG override' too in some situations, just try whatever works for you.

45
[Max] General Discussion / Re: Price Increase
« on: 2024-01-11, 17:06:02 »
Just had an email from Chaos informing of another 10% price increase to an annual Corona Premium Subscription, this coming after last years 100%+ increase.  Thoughts people?
Just read the email. If I remember correctly the last price increase came with a comment along the lines of "this will allow us to keep the price stable for the next years".

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