programing a raytracer

[IanT]

It's most likely to be self-intersection (e.g. the shadow ray from plane->light thinks it's intersecting the plane due to rounding errors).

Here's what I have for the plane intersection test:

Code: Select all

    double t;
    ...
    t = (-ray.o.y) / ray.v.y;
    if (t > Const.EPSILON && t < tMax) {
        return new IntersectionState(this,t);
    } else {
        return null;
    }
    ....

ray.o is the ray origin and ray.v is the ray direction. Note the "t > Const.EPSILON" test ... this is what you need to prevent self-intersection. EPSILON in this case is defined as 1.0e-8 (0.00000001).

The above is just a test for a plane centred at <0,0,0> and with the normal pointing along the Y-axis (the ray will already have been transformed into the shape co-ordinate system before this code is called).

Probably the only change you need to make is to define an EPSILON somewhere and change....

Code: Select all

        if (T <= 0) { 
            T = -1; 
            trueHit = false; 
        } else{ 
            trueHit=true; 
        }

to...

Code: Select all

        if (T <= EPSILON) { 
            T = -1; 
            trueHit = false; 
        } else{ 
             trueHit=true; 
         }

Of course, this might not be the problem but that artifact is certainly very familiar to me

Ian.

[oodmb]

it was the problem you have stated- actually very easy to fix. only reason i didn't suspect it was because i had used an objID system to prevent primitive objects from self shadowing- what i did forget to do is to use exclude for objID in the ray checking boolean so it wasn't using my system that i had already implemented.

[IanT]

it was the problem you have stated- actually very easy to fix. only reason i didn't suspect it was because i had used an objID system to prevent primitive objects from self shadowing- what i did forget to do is to use exclude for objID in the ray checking boolean so it wasn't using my system that i had already implemented.

You should probably stick to the EPSILON method for all intersection tests otherwise you might run into problems once you implement glass

Ian.

[oodmb]

infinite plane is working as is everything else in my renderer



oh, the objID is only in the shadow pass. i have different methods for different types of intersections that can be called by different materials.

[IanT]

Cool

So, are you going to go down the unbiased route? Now you have the basic intersection and image creation stuff going, you should decide soon

Ian.

[oodmb]

I think I'm going to not decide until i get triangle intersections and normal smoothing in.

i'm probably going to go with a hybrid where different levels of bias can be chosen.

[IanT]

I think I'm going to not decide until i get triangle intersections and normal smoothing in.

i'm probably going to go with a hybrid where different levels of bias can be chosen.

That definitely sounds like the best plan.

Ian.

[oodmb]

is it "acceptable" to have the vertex normals be in the scene file?

[IanT]

is it "acceptable" to have the vertex normals be in the scene file?

I'd say it's essential unless you plan on always calculating them yourself.

It's possible but it's usually much better to rely on the 3D modelling app to do this for you. Some apps do it better than others ... one example of "not done very well" is Blender, which seems to ignore the minimum smoothing angle as far as the exporter is concerned

Ian.

[Kram1032]

minum smoothing leverl???
If you want a sharp edge, use edgesplit.
(Dunno, if you meant that, though)
I like that colour! It looks something like chocolate

[oodmb]

Code: Select all

I'd say it's essential unless you plan on always calculating them yourself.

YAY!!!! less work for me!!!!

[IanT]

minum smoothing leverl???
If you want a sharp edge, use edgesplit.
(Dunno, if you meant that, though)
I like that colour! It looks something like chocolate

Yes, but a user can quite happily model a mesh, set the smooth angle, click "Set Smooth" and it will render fine with the Blender Render. Exporting it will result in screwed-up normals unless EdgeSplit has been explicitly used.

Trust me, it happens a lot

Ian.

[oodmb]

i dont realy ever use smoothing groups anyway, i usualy use edge split... guess my highpoly modeling was actualy avoiding an error!

[Kram1032]

no screwed up normals...
just smoothing artefacts.
It's just, that a 90° edge can't be smooth in indigo.
It's an indigo issue, not a blender one.

"set smooth" can be used together with "edge split"

[IanT]

no screwed up normals...
just smoothing artefacts.
It's just, that a 90° edge can't be smooth in indigo.
It's an indigo issue, not a blender one.

"set smooth" can be used together with "edge split"

It's a Blender inconsistency.

Try the following:

1. Create a cylinder mesh
2. Set smooth angle to 30
3. Click "Set Smooth" for the cylinder
4. Render it with the internal Blender Render

You'll see that it looks fine.

5. Export it to Indigo and render

You'll see the normals are NOT smoothed according to the smoothing angle that you set in Blender

Try again with an extra step...

4a. Use EdgeClip to enforce edges

Then you'll see the normals are fine.

My point is ... a user can model a scene, render it with Blender Render and think that everything is OK when, in fact, it isn't.

Obviously Blender Render infers more information than it's given by the base mesh object, which can be confusing to the user when they're using an external renderer.

As I said, I've rendered plenty of .blends that people have provided. They look fine when rendered with Blender, but not after they're exported.

Ian.