Indigo Renderer Forum

Heya guys,

I wanted to work on a scene for one of my favorite games ... GO (Wei-Qi).

Here a first pic I did for testing purposes and to find the right materials.
Well, my problem is obvious ... somehow I've got some strange smoothing
going on. Now I'm wondering if this is a problem of Indigo or the exporter.
Any info on this matter is highly appreciated.

1. resized picture (1280x960 to 800x600):



2. resized and croped pictures (150% zoom):




3. wires (white: ISOlines / grey: smoothed view):



Note: This scene is illuminated by a flashlight* only.
* very small meshlight close to the camera to simulate a flashlight

edit: After 25 minutes rendering of the same scene but this
time over the .3ds export and not the .xml ... it seems to be the
exporter that is causing this problem in the .xml ... .. .

Grrrreeeeeeeeeegooor!!!?

ps.: U3dreal, don't worry mate ... I guess it's not that easy to get it right.
Take a look at Maxwell, ... they have jagged shadows ... ^^

edit 2: I'll let it render longer to be sure about this issue. ;o)

Thanx in advance! ;o)


take care
psor

i think this are these jagged shadows
http://www.maxwellrender.com/forum/view ... hp?t=17941

Yup manitwo! ;o)

Could be a related problem ... but I'm not familiar with the whole
stuff ... so I'm not able to dig deeper into it.

edit: I'll put an exporter bug report together later ...


take care
psor

but I'm not familiar with the whole
stuff ... so I'm not able to dig deeper into it.

.. unfortunatly me too.
But i bet it's not a problem of the exporter
btw: nice clean render (except the mentioned problem )

manitwo wrote:

but I'm not familiar with the whole
stuff ... so I'm not able to dig deeper into it.

.. unfortunatly me too.

But i bet it's not a problem of the exporter

I wouldn't bet on it right now ... the .3ds export seems to work fine.

btw: nice clean render

Thanx manitwo! Took about 24h ... dunno I guess I could have
stopped it earlier ... but I was not at home ... hehe. ;o))

edit: Just a quick post to give an overview ...

1. .3DS export instead of .XML / 1h rendertime (1280x960 croped)


Yup no texture, ... other issue with the exporter ... but will dig into it later.



take care
psor

So it's an exporter problem?
I wouldn't be suprised however if it's an Indigo problem, smoothed normals are an artifact minefield, especially in unbiased GI renderers

Oh, and nice scene!

Well Nik, ... I'm not so sure about that yet. What I can say is, that
the .XML output seems to be totaly different than the .3DS output.
But I'll have to investigate a bit more to be sure about that.

I will check that later today, ... ;o))

edit: Hehe thanx! It's just a start I will see where it goes.


take care
psor

Nick, this reminds me of a similar problem I sometimes have with normals:



When the local contribution is calculated on a surface with interpolated normals like the one above, the renderer thinks that the point is unoccluded (disregarding non-local surfaces) because the dot product between the light and (interpolated) normal is greater than 1. However in reality the horizon of the triangle is in the way. This can cause ugly discontinuities in illumination.

P.S. If you know this is not the case, how did you find a way around it?

EDIT: Culling back-facing, opaque polygons from intersection testing is one way of stopping it, but that can raise problems elsewhere.

Hmm, ... something is really off ... but I can't tell what the heck is
going on ... *LOOOL* The normals seem to be flipped,
from my point of view .... but I wear glasses so ... ;o))

1. 3DS export (that's how it should look like)


2. XML export


Note: Since I'd the feeling that the normals are flipped I flipped them
and exported the scene again, but since Indigo renders all materials twosided
... it shouldn't matter ... and it did not. Hope someone can get more
out of it ... hehe. ;o)


take care
psor

what's about some rounding in the XML exporter? What are the precission of the exporter normals?
Let's say a normal was (0.84834984 / 0.23232321 / 0.12398238) and by XML export it lost some precission by rounding to (0.848 / 0.232 / 0.123). You can check in the XML howmany digits the exporter uses for normal vectors. I think 4 to 5 digits should be enough... was just an idea but as longer i think on it, i don't believe it's the case here
nice render anyway

Beltane wrote:Nick, this reminds me of a similar problem I sometimes have with normals:



When the local contribution is calculated on a surface with interpolated normals like the one above, the renderer thinks that the point is unoccluded (disregarding non-local surfaces) because the dot product between the light and (interpolated) normal is greater than 1. However in reality the horizon of the triangle is in the way. This can cause ugly discontinuities in illumination.

P.S. If you know this is not the case, how did you find a way around it?

EDIT: Culling back-facing, opaque polygons from intersection testing is one way of stopping it, but that can raise problems elsewhere.

Yeah, i have lots or problems like this ,not sure if I have the exact same problem tho. Veach talks quite a lot about this issue in chapter 5 of his thesis, have a look at that if you haven't already.

Ono-Sendai wrote:Yeah, i have lots or problems like this ,not sure if I have the exact same problem tho. Veach talks quite a lot about this issue in chapter 5 of his thesis, have a look at that if you haven't already.

That's incredibly useful. Thanks a lot!