And finally I'm going to implement very simple Java raytracer in
POV-Tree. The purpose of such raytracer will be to prepare tree
image with alpha channel (png...) which could be used as
image map. So that even people who don't use POV-Ray could
generate such images from POV-Tree.

The only object which could be supported in such raytracer could
be UV mapped triangles (with transparency (tree's leaves).

Right now when POV-Tree exports POV-Ray mesh file it doesn't
keep all generated triangles in memory because with very detailed
tree it's very easy to get 'Out of Memory' exception. Instead
POV-Tree generates triangles on the fly and saves to the file only
small amount of triangles going from one tree element to another.

Is it possible to do the same for raytracing? Is it possible
to avoid generation of all triangles and keeping them in memory?
Is it possible to generate on the fly only triangles which are
necessary for current rendering line? The first problem I see here
are shadows. Has anybody tried to do smth. like this? Maybe
somebody knows any resources about this subject?

Here are some simple Java raytracers which I found on the
Internet:
http://tigrazone.narod.ru/rtjar.html
http://www-scf.usc.edu/~csci480b/demo5/kneedy/RayTrace.html
http://www.hut.fi/~msell/raytracer/raytracer.html
http://www.cs.nyu.edu/ms_students/dagl7643/spheres/

Thanks in advance!

Gena.

Post a reply to this message

Gena <gen### [at] yahoocom> wrote:
> Is it possible to do the same for raytracing? Is it possible
> to avoid generation of all triangles and keeping them in memory?

  Yes, and it has been implemented in many "pro" renderers.

  In scanline rendering it's definitely easier to be selective on what
you are rendering and what not, and to take turns between objects to
render them (that is, you can render first one object and then another
and then compose the two results using their depth maps).
  In raytracing it's equally easy if you are not using reflection nor
refraction and you are using the same lighting tricks as the scanline
renderer (ie. eg. shadow maps instead of raytraced shadows). However,
since in raytracing you usually want raytraced shadows and reflecting
and translucent objects, it becomes a bit trickier.
  You can, for example, use a caching scheme where you load only those
objects which bounding box are hit during the raytracing process. When
more and more objects are loaded and the memory is being filled, you
can drop the oldest hit objects from memory.
  If an object is extremely complex (such as a tree with hundreds of
thousands of triangles) you can even divide these objects into
subobjects and perform the caching on them. That is, instead of loading
the whole tree, just load a properly sized section of it which bounding
box is being hit right now.
  Octree spatial subdivision of meshes (which is AFAIK what POV-Ray uses
for speedup of raytracing meshes) can be a very big help in this. That is,
just load those octree nodes which need to be loaded and forget about
those which don't. (Of course you shouldn't have nodes with one triangle
in them because that would cause too much overhead; the size of the
subobjects should be something optimal.)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Gena <gen### [at] yahoocom> wrote in news:4084a462@news.povray.org:

> And finally I'm going to implement very simple Java raytracer in
> POV-Tree. The purpose of such raytracer will be to prepare tree
> image with alpha channel (png...) which could be used as
> image map. So that even people who don't use POV-Ray could
> generate such images from POV-Tree.
...

> Here are some simple Java raytracers which I found on the
> Internet:
...

You may also have a look at RaJa: http://raja.sf.net
It seems that its development has stopped or heavily lagging behind, but 
you could use its code as a foundation (you must add support for uvmapped 
and transparent triangles)

--
Alessandro Falappa

Post a reply to this message

If you don't need reflections or refractions, a z-buffer approach might be the 
better choice here because it's got no memory problems when rendering zillions 
of triangles (as they are passed through the pipeline one by one).

If you need shadows, you could precompute shadow-maps for each lightsource. For 
transparency, a modified z-buffer (which stores a list of rgba-colors and 
z-values for each pixel) is needed. For the things you described, Java3D or one 
of the Java OpenGL wrappers might have all the features you're looking for - if 
not, I have written some Java code that uses a zBuffer to render phong-shaded 
triangles (but without transparency yet), just send me an email if you are 
interested in the code.

If you need very high resolutions or high levels of supersampling, you'll 
quickly run into another memory problem with this approach: you'd need to store 
at least color and z-value for each pixel (with the modified "transparency" 
version even more) in memory. The usual solution is to render "buckets", e.g. 32 
x 32 pixel regions - so you would end up with something like REYES.

There's even a RenderMan compatible REYES renderer, written in Java, out there - 
check out http://jrman.sourceforge.net

-Sascha

Post a reply to this message

Sascha Ledinsky wrote:
> If you don't need reflections or refractions, a z-buffer approach might 
> be the better choice here because it's got no memory problems when 
> rendering zillions of triangles (as they are passed through the pipeline 
> one by one).

In my case there is no need in reflections and refractions
and I don't mind to use zBuffer if it provides realistic
result.

> If you need shadows, you could precompute shadow-maps for each 
> lightsource. For transparency, a modified z-buffer (which stores a list 
> of rgba-colors and z-values for each pixel) is needed. For the things 
> you described, Java3D or one of the Java OpenGL wrappers might have all 
> the features you're looking for - if not, I have written some Java code 
> that uses a zBuffer to render phong-shaded triangles (but without 
> transparency yet), just send me an email if you are interested in the code.

I'd like to refrain from using Java3D, JOGL etc. for now.
Does your program create triangles on the fly? Do you need
to sort them along Z axis?

> There's even a RenderMan compatible REYES renderer, written in Java, out 
> there - check out http://jrman.sourceforge.net

Thank you for the info.

Gena.

Post a reply to this message

> I'd like to refrain from using Java3D, JOGL etc. for now.
> Does your program create triangles on the fly?

Currently it reads the triangles from file, each triangle is rendered 
immediately, so there's no need to store a large number of them in memory.
Of course you could pass the triangles directly to the renderer.

> Do you need to sort them along Z axis?

No, although there might be a slight speed improvement if they were.

Supported:
+ perspective correct interpolation of normals and z-values
+ phong shading
+ support for POV-like ambient, diffuse, brilliance, specular and roughness
+ rgb colors
+ unlimited amount of directional or point lights

Not supported:
- no u/v mapping yet
- no transparency yet
- no shadows yet

I've posted an image rendered with it to p.b.i

What kind of license do you use for POV-Tree?

-Sascha

Post a reply to this message

Sascha Ledinsky wrote:
> Supported:
> + perspective correct interpolation of normals and z-values
> + phong shading
> + support for POV-like ambient, diffuse, brilliance, specular and roughness
> + rgb colors
> + unlimited amount of directional or point lights

Sounds good.

> Not supported:
> - no u/v mapping yet
> - no transparency yet
> - no shadows yet

That's actually very important functionality in my case.

> I've posted an image rendered with it to p.b.i

Thank you.

> What kind of license do you use for POV-Tree?

I don't distribute source code since version 1.1
because we decided (Tom Aust and me) to try to
make commercial version. But that's still a plan...
But because of that fact I also cannot use anybody's
code and I have to do almost everything myself. I would
be glad to colloborate with anybody but at this stage
it would be unfair from my side to promise anything.

Gena.

Post a reply to this message

Gena wrote:

>> Not supported:
>> - no u/v mapping yet
>> - no transparency yet
>> - no shadows yet
> 
> That's actually very important functionality in my case.

u/v mapping and transparency would be easy to add. Shadow-maps are a bit more 
tricky...

> I don't distribute source code since version 1.1
> because we decided (Tom Aust and me) to try to
> make commercial version. But that's still a plan...
> But because of that fact I also cannot use anybody's
> code and I have to do almost everything myself. I would
> be glad to colloborate with anybody but at this stage
> it would be unfair from my side to promise anything.
> 
> Gena.

I thought that this might be a problem. My code is part of another application I 
write, which is GPL'd, so it cannot be used in a commercial application.

Anyway, for raytracing huge numbers of triangles, a "simple" raytracer won't do, 
you'd need some more sohpisticated algorithms like octrees, vista-buffer, etc. 
to get a reasonable performance.
So I'd suggest to start with a zBuffer approach.

I've found this document to be quite helpful, I used 1/z to interpolate the 
normals for phong shading, and of couse it can be used for u/v mapping too:
http://easyweb.easynet.co.uk/~mrmeanie/tmap/tmap.htm

-Sascha

Post a reply to this message