CoolColJ's test pics thread

[CoolColJ]

Indigo's mesh subdivision messes up the UVs

To be exactly, the smoothing parameter does: http://www.indigorenderer.com/forum/vie ... 387#p90387

My "workarround" for this is to have some good basic subdiv done in your 3D app and then use a viewdependend Indigo Subdiv on it ithout smoothing checked.
Costs RAM & Export, render start time, but thats the price to pay...

I still get it even without smoothing on!
View dependant is also on

[CTZn]

The boolean to turn off is subdivision_smoothing, and turning normal_smoothing off too is ok for crispy stones.

[CoolColJ]

this the code in my scene for the pool mesh, as you can see it still messes up

I don't even know what the wrap U/V does, since it doesn't seem to make any difference either, whether it's set true or false

<mesh>
<!--Pool-->
<name>CCJ_Cindigo-4.igmesh</name>
<normal_smoothing>false</normal_smoothing>
<external>
<path>G:\Renderers\INDIGO v2\Scenes\models.CCJ_Cindigo\CCJ_Cindigo-4.igmesh</path>
</external>
<merge_vertices_with_same_pos_and_normal>false</merge_vertices_with_same_pos_and_normal>
<max_num_subdivisions>3</max_num_subdivisions>
<subdivide_pixel_threshold>1</subdivide_pixel_threshold>
<subdivide_curvature_threshold>0.1</subdivide_curvature_threshold>
<displacement_error_threshold>0.001</displacement_error_threshold>
<subdivision_smoothing>false</subdivision_smoothing>
<view_dependent_subdivision>true</view_dependent_subdivision>
<wrap_u>true</wrap_u>
<wrap_v>true</wrap_v>
</mesh>

[Zom-B]

Code: Select all

<wrap_u>true</wrap_u>
<wrap_v>true</wrap_v>

This was introduced to "fix" uv distortion with subdiv+smooth.
Please set it to false and try again!

[CoolColJ]

Code: Select all

<wrap_u>true</wrap_u>
<wrap_v>true</wrap_v>

This was introduced to "fix" uv distortion with subdiv+smooth.
Please set it to false and try again!

I tried it, and while it changes the texturing, it's still warped and stretched

----


The render with 1000 bounces, and 0.003 of cauchy_b (dispersion)
Firstly I think this is way too much dispersion for water, it should more like 0.0013.

And the water has way too much absorption for clean natural water at 1 metre or so depth. I original took the values exactly as they were shown in the a research article and formated them into 83 values for Indigo's tabulated spectrum format. They were in m^-1 units, but perhaps I need to divide them by 10.

Some of the materials were tweaked a little, but you can see a few more details/cautsics vs the 100 bounce version. Probably needs more time to render

---

A little side note - I tried Thea render recently, and while you can get pool caustics in the included sample scene, which seems to be cheating somewhere or something, as soon as I use my own scene and material..no caustics...

Now Luxrender can do pool caustics with Bidirectional MLT, but it takes ages to fully develop, but the sky and directly lit surfaces do clear way faster than Indigo. It doesn't have that smudgey look of Indigo's MLT, looks more like path tracing. It's almost like a hybrid of path tracing and MLT...

[CoolColJ]

The colour seems to be pretty close to the real thing
these photos are of natural water pools - no chlorine etc
I guess this is not pure water though

[CTZn]

as you can see it still messes up

Which image is it ? I assume the remaining artefact is along walls borders, is it ?

If so export the walls with smoothed normals and set merge_vertices_with_same_pos_and_normal to true. Even if smooth wall normals looks wrong in blender, its faces will remain stitched. And the overall shape preserved by having disabled subdivision's surface smoothing (the feature bugging UVs, wrapping doesn't help really).

If that's not it then showing the last issue with displacement you experienced should help, I'm pretty sure it can be worked around.

PS: My two cents but I would leave curvature threshold at zero by default when using view-dependent subds.

[CoolColJ]

as you can see it still messes up

Which image is it ? I assume the remaining artefact is along walls borders, is it ?

If so export the walls with smoothed normals and set merge_vertices_with_same_pos_and_normal to true. Even if smooth wall normals looks wrong in blender, its faces will remain stitched. And the overall shape preserved by having disabled subdivision's surface smoothing (the feature bugging UVs, wrapping doesn't help really).

If that's not it then showing the last issue with displacement you experienced should help, I'm pretty sure it can be worked around.

PS: My two cents but I would leave curvature threshold at zero by default when using view-dependent subds.

It's the same stone texture I've been using with this scene

I give up trying to displace this pool wall....
It either stuffs up or it crashes Indigo, no matter what settings I use!

Using a basic cubic water mesh, and displacing and subdividing it works perfectly

[CoolColJ]

I noticed that Indigo tends to render caustsics in my pool scene differently, ie like 10 times slower, when the pool walls/floor are bump mapped

Luxrender had the same issue with the same scene, same for Thea render. Now I've been using the same scene, texture and bump map for testing everytime. And there might be some issue with bump mapping it seems

Lux render - No bump map vs with bump map


Thea render had the same issue.


I sent them the same scene. Here was the reply, which might help

i had a look at your scene and there seems to be a bug with bump map scaling ( bump map strength ) .... thank you very much for sending us this scene ..... using a different bitmap/bump map works perfect ... so i guess it is related with some bitmaps ...

If Ono wants a copy of the scene in Indigo format + textures for bug testing, let me know, because it's an annoying issue

[notareal]

In Thea it will help if you don't use IOR 1.0 for pool walls and floor.

[CoolColJ]

In Thea it will help if you don't use IOR 1.0 for pool walls and floor.

makes no difference either way, it's the bump mapping that does something funny. As soon as I reduce the strength of the bump map by a lot, somehow things improve.

I'm guessing it confuses the path tracing engine or something.
I tried a few different bump maps, and it doesn't seem to make any difference.

[CTZn]

Too bad that you are givng up with your displaced walls, but anyway I forgot about that nasty 2.4.3 crash when surfaces use displacement and albedo together...

Does bump mapping behave the same with a rgb and a grayscale texture ? I'm wondering wether the number of channels is playing a role in the issue but I have no clues...

[CoolColJ]

does that crash happen with v2.2? Will have to try it in the older stable versions

[CTZn]

no such crashes with 2.2 (aka 2.0 stable) indeed.

StompinTom was the first to declare the bug in the 2.4 thread.

[CoolColJ]

An old render I never got around to showing. Straight output from Indigo. Pre v1.00 from memory

I did this in Sketchup back when I was fiddling around with it, but modelled in C4D. Haven't tried to play around with the better tone mapping features of the newer versions with it

Alien Pillars