 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ee0e6b6@news.povray.org>, "Shay" <sah### [at] simcoparts com>
wrote:
> I'm waiting patiently for the camera_view pigment and perhaps at a later
> date a scene pigment where a pigment is taken from an entirely separate
> scene.
I'm not sure how feasible that second one would be. It would require
duplicating all the internal data structures, something that POV is not
designed for. You would be better off just putting the camera in another
area of the same scene.
> The point of my response however is to ask how polygon displacement can
> do anything which isosurfaces cannot do. I would like some clarification
> because now I really cannot see the point.
Some displacements and deformations just can't be done with an
isosurface. For example, anything that causes the surface to penetrate
itself, or a surface rippling simulation. In addition, complex
isosurfaces can get quite slow, and there are graphical modellers for
meshes.
> What would be interesting is a set of mesh structures which could be
> "built" when rendering and require less memory usage. For example, a
> mesh box which would only need 8 vertices stored in memory. PoV-Ray
> would know where the 12 triangles should be. This would be most useful
> for grass, tiny spaceship details, flower petals, etc.
The example you describe sounds too fine-grained. However, it might be
useful to store triangles as quads, strips, and fans. Indexes for each
vertex in the shape would be stored stored once for the shape, instead
of once per triangle in the shape.
However, this would slow things down by more than just the overhead of
supporting the new object: these shapes would be larger in size, so
their bounds would be hit more often, and they would have linear time
complexity (computation time would be linearly related to number of
triangles in the shape). Quads usually aren't much bigger than either of
the triangles they would replace, so they might not be slowed down much,
but a long triangle strip would perform quite badly. And even if these
composite shapes were reduced to individual triangles during parsing,
this idea could greatly reduce parsing time and mesh file sizes.
Another idea I've been thinking of trying in my own raytracer is to
store vertices with point, normal, UV, and texture information,
replacing these four indices in the triangle structure with a single
index. In some meshes, this could save a fair amount of memory. (storing
3 longs instead of 12 in the triangles)
> Even better would
> be some way to define a set list of triangles (as vertex list
> references) for any list of the correct number of vertices. Just
> throwing this out there. I've of course got no idea how to implement it.
A generalization of the above idea? It might be useful in a few cases.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Tessellation: I'm working on my own tessellation patch. Others have done
> general tessellation methods, I'm doing shape-specific methods. So far
> I've got nice tessellations for spheres, cylinders, cones, and a few
> other shapes.
Cool. I need tesselation services as well, both for
OpenGL previewing and (possibly later) scanline rendering.
I mean, why have my wireframe previewer go the trouble
of tesselating each primitive when your code is doing that?
Is any info available on your tesselators?
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ee4061a@news.povray.org>,
"Ray Gardener" <ray### [at] daylongraphicscom> wrote:
> Cool. I need tesselation services as well, both for
> OpenGL previewing and (possibly later) scanline rendering.
> I mean, why have my wireframe previewer go the trouble
> of tesselating each primitive when your code is doing that?
> Is any info available on your tesselators?
It's nothing really special, just a huge pain to code. I added a
tessellation method to each object. Most primitives will have at least
one specialized method as well as access to a general method such as
marching tetrahedrons. Infinite shapes will have to have boundaries
defined. I hope to eventually have CSG use the specialized method for
the component shapes and process the meshes together, but need to
research mesh processing algorithms some more.
How does your preview currently function? An OpenGL preview was one of
the ultimate goals of my patch, but I never got started on it.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> such as marching tetrahedrons.
I don't know how the marching triangles algorithm works, but the few
bits I have read about it promise that it should give a very good result
(probably much better than a marching cubes or one of its derivatives).
Perhaps it should be worth trying.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ee4497b@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > such as marching tetrahedrons.
>
> I don't know how the marching triangles algorithm works, but the few
> bits I have read about it promise that it should give a very good result
> (probably much better than a marching cubes or one of its derivatives).
> Perhaps it should be worth trying.
Marching triangles would be an ideal general method, but quite a bit
more difficult to implement. I'll look into it, but I'm mainly focusing
on the object-specific tessellations, I planned to incorporate one of
the existing general tessellation patches. Marching tetrahedrons seems
to give fairly good results without any patent issues. The main reason
I'm writing this patch is so I can get meshes of arbitrary objects for
improved proximity pattern, curvature pattern, and glow patches.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I hope to eventually have CSG use the specialized method for
> the component shapes and process the meshes together, but need to
> research mesh processing algorithms some more.
>
You might be interested by the GTS project on source forge.
At least, as inspiration for your code, unless you're successful at
mixing the licenses...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Is any info available on your tesselators?
>
> It's nothing really special, just a huge pain to code. I added a
> tessellation method to each object. Most primitives will have at least
> one specialized method as well as access to a general method such as
> marching tetrahedrons. Infinite shapes will have to have boundaries
> defined. I hope to eventually have CSG use the specialized method for
> the component shapes and process the meshes together, but need to
> research mesh processing algorithms some more.
(Sorry I didn't respond sooner; I somehow totally
forgot this thread.)
I'll have to look at that, since I'm now adding solid
rendering to the OpenGL patch. My approach to CSG would be
along the lines of:
primitive::render()
{
tesselate primitive
for each tesselated polygon
if it is not totally clipped away by the CSG then
if it is totally inside the visible CSG volume then
render the polygon
else
make a tesselatable triangle primitive out of the polygon
triangle.render(); // recurse
endif
endif
next polygon
}
So, similar to REYES, "troublesome" polygons simply
get broken up into smaller and smaller pieces until
the CSG test becomes as easy as raytracing. The user
can also tune the dicing recursion level to trade
quality vs. speed. The only real hard part is making
good inside/outside determiner routines for a triangle checked
against each of the possible primitives. A lazy routine would
treat more polygons as needing dicing, slowing things down.
An obvious general determiner is:
state triangle::intersectsVolume(volume)
{
if all of the triangle's points are outside volume then
return tri_outside
else if all of them are inside the volume then
return tri_inside
else return tri_intersects_volume
}
This would fail in special cases, like a triangle
whose plane is tangeant to a sphere and not quite
as far from the sphere's center as its radius.
The tri's points could all be outside, but the
center of the tri would not. What's interesting is
that again, a little recursion would resolve this
too in a general-purpose way. As long as you have
a point-within-primitive determiner and some patience,
recursion will suffice. I imagine complex isosurfaces
in CSG would be very compute intensive this way,
but then again, isosurfaces are better suited to
a raytracing paradigm.
> How does your preview currently function? An OpenGL preview was one of
> the ultimate goals of my patch, but I never got started on it.
The details are in the patch's readme.txt, but what I did
yesterday was to add a Render_Style INI parameter to treat
scanlining and raytracing as selectable render methods.
The options are
PARSE 0
WIREFRAME 1
SCANLINE 2
RAYTRACE 4
They can be or'd together except for wireframe and scanline,
since 'scanline' means 'solid'. So if you say 'Render_Style=5'
in the command line, the render window will display a wireframe
version of the scene, following by a raytraced version.
Option zero (the absence of all render styles) is useful just
to see how long parsing alone takes, or to test a bunch of
.pov files to see that they don't have syntax errors.
Now I can do 'Render_Style=1' in an .ini file, and emit
wireframe animation clips. As one would guess, they
emit pretty fast.
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rohan Bernett <rox### [at] yahoocom> wrote:
> Let's make a nice big list of all the features people would like to see in
> an official/unofficial version of POVRay!
A classic request has been a 'no_antialiasing' keyword which could be
applied to objects and the sky_sphere.
The functionality is simple: When a ray hits such object, then no more
antialiasing rays are shot for that pixel.
An alternative, perhaps more elaborated functionality could be this:
All necessary antialiasing rays are shot, but if all of them hit a
no_antialiasing object, then only one of the rays is taken into account
(the one which would have been shot if no antialiasing had been used).
(This helps antialiasing the borders of an object which is in front of a
no_antialiasing object.)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ef15629@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> An alternative, perhaps more elaborated functionality could be this:
> All necessary antialiasing rays are shot, but if all of them hit a
> no_antialiasing object, then only one of the rays is taken into account
> (the one which would have been shot if no antialiasing had been used).
> (This helps antialiasing the borders of an object which is in front of a
> no_antialiasing object.)
One of my ideas is some way of increasing the weighting of an object. A
very thin mesh of a hair or grass blade would then contribute to the
color of a pixel even when it is only hit by a few samples, instead of
being antialiased into oblivion. Or a star would shine brightly even
when it only covered a small area of a pixel. Maybe you could increase
the weighting depending on the distance the rays have traveled...maybe
even using ray differentials.
One of the other things that needs to be done is to do clipping after
the antialiasing. An extremely bright object should contribute more to a
pixel than just a white one. However, because simple clipping is used,
this makes super-bright objects appear unantialiased...I think an
antialiasing filter could be designed that avoided this, though. Or just
save to a high dynamic range format and let someone else worry about
clipping. ;-)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ef133dd$1@news.povray.org>,
"Ray Gardener" <ray### [at] daylongraphicscom> wrote:
> So, similar to REYES, "troublesome" polygons simply
> get broken up into smaller and smaller pieces until
> the CSG test becomes as easy as raytracing. The user
> can also tune the dicing recursion level to trade
> quality vs. speed. The only real hard part is making
> good inside/outside determiner routines for a triangle checked
> against each of the possible primitives. A lazy routine would
> treat more polygons as needing dicing, slowing things down.
This may be useful for scanlining, but what I'm after is a method for
generating meshes for general use. For just raytracing, it would be
possible to just use an ordinary CSG of solid meshes, but then you have
to store the CSG structure, you end up with a CSG instead of a mesh.
What needs to be done is remove some triangles and add some new ones to
lace up the edges. Subdivision at this point will be useful, but not to
micropolygons...the triangles need to be stored, render-time subdivision
would require information about the CSG structure. It may not be
necessary though...things like proximity and glow effects (two other
things I plan to use tessellation with) may work fine with simple
quick-and-dirty removal of triangles that are entirely contained in
another object.
> > How does your preview currently function? An OpenGL preview was one of
> > the ultimate goals of my patch, but I never got started on it.
>
> The details are in the patch's readme.txt, but what I did
> yesterday was to add a Render_Style INI parameter to treat
> scanlining and raytracing as selectable render methods.
> The options are
What I actually meant was: how are you tessellating and drawing the
objects? Did you add an object method to draw in OpenGL, or one to
tessellate to a mesh which is used by drawing code elsewhere? Or
something else?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
