This I GOT.  This works fine if you want to reiteratively place objects on your
scene.  It does not provide me any means of ascertaining the height on the
heightfield for individually placed items.

A simple scattering loop looks like this:

#declare R1=seed(3838)
#declare Count=1
#while (Count<100)
    #declare X=rand(R1)*100
    #declare Z=rand(R1)*100
    #declare Y=somefunction(HFNAME, X,Z,100,100)
    object{TheTHING translate<X,Y,Z>}
    #declare Count=Count+1
#end

This does a random scatter of 100 items across an area bounded 0,0,0 to 100,?,100
where "somefunction" delivers the Y coordinate.

Schrammel's toolkit is wonderful but very complicated to setup and use for the
kind of work I want to do with POV.  The above example would work fine with his
tool since it only uses 1 item named "TheTHING" ... however, my "TheTHING" becomes
an entire case statement where "TheTHING" can be any of a hundred items (depending
on what I'm rendering, this can be more or less).

In order to use the utility, EACH and every item in the 100 items would have to
have the program run 1ce for each item.  Then all the output files combined to
render it.  If any of the items collided, I couldn't just change the seed R1 value
to resolve them, I'd have to regenerate EVERY one of the include files generated
and hope that they didn't collide again.

Bob Hughes wrote:

> Genesis Toolkit by Schrammel can do this. Check here:
>
> http://www.rhein-ruhr.de/~schrammel/index.htm
>

Post a reply to this message

> I have personally seen the difference between a program written in pure
> C, another version in C+ASM, and a pure ASM version. Needless to say,
> the ASM version kicked the C version,

Yeah, but C (or C++) isn't the best language to be optimizing for. There's a
story about Ada running circles around assembly - a newly hired Ada programmer
with only a dab of experience wrote code that outperformed what a team of
experienced assembly programmers came up with.  I can't find the URL for that
story, but it's been passed around a lot in Ada circles.  Like chess playing
programs, it's not smarts, but applying simple rules that humans understand
just fine, but unrelenting, more combinations and moves ahead. Turns out
there's almost always nothing to be gained by using clever opcodes, except on
older CPUs like the 486.  Pipelining in the Pentium is a more important
concern.


More stuff at 
http://www.acm.org/sigada/news/news.html 
and
http://www.adahome.com/

And as long as I'm on my favorite soapbox, anyone thinking of switching from C
or C++  to something capable of global optimizations, should pay a visit to
http://www.m3.org/.  (Ha, my only published ray tracing from all of 1998)


For anyone wanting to stick with C or C++, you gotta look into the PGCC
compiler with Pentium optimizations (good for all platforms using pentium and
any flavor of unix, heck, maybe there's a win32 port?)   

But for totally cross-platform optimizing, use a platform  independent language
like Ada-95 or Modula-3, and let the compiler do all hard work.

-- 
Daren Scot Wilson
dar### [at] pipelinecom 
www.newcolor.com
----
"Ada 95 is about the best language out there
 and people are beginning to notice. C++ seems to be evolving 
 into a monster and people cannot fail to notice that."
              -- Michael Rohan

Post a reply to this message

Robert J Becraft wrote:
> 
> This I GOT.  This works fine if you want to reiteratively place objects on your
> scene.  It does not provide me any means of ascertaining the height on the
> heightfield for individually placed items.
> 
> A simple scattering loop looks like this:
> 
> #declare R1=seed(3838)
> #declare Count=1
> #while (Count<100)
>     #declare X=rand(R1)*100
>     #declare Z=rand(R1)*100
>     #declare Y=somefunction(HFNAME, X,Z,100,100)
>     object{TheTHING translate<X,Y,Z>}
>     #declare Count=Count+1
> #end
> 
> This does a random scatter of 100 items across an area bounded 0,0,0 to 100,?,100
> where "somefunction" delivers the Y coordinate.
> 
> Schrammel's toolkit is wonderful but very complicated to setup and use for the
> kind of work I want to do with POV.  The above example would work fine with his
> tool since it only uses 1 item named "TheTHING" ... however, my "TheTHING" becomes
> an entire case statement where "TheTHING" can be any of a hundred items (depending
> on what I'm rendering, this can be more or less).
> 
> In order to use the utility, EACH and every item in the 100 items would have to
> have the program run 1ce for each item.  Then all the output files combined to
> render it.  If any of the items collided, I couldn't just change the seed R1 value
> to resolve them, I'd have to regenerate EVERY one of the include files generated
> and hope that they didn't collide again.
> 
> Bob Hughes wrote:
> 
> > Genesis Toolkit by Schrammel can do this. Check here:
> >
> > http://www.rhein-ruhr.de/~schrammel/index.htm
> >

  If it's just random distributed points (locations for "TheTHING" )
on a terrain then you are looking, for Ray Gardeners program Leveller,
has this function available. It allows you to choose some variables of
the process, such as % per grid point or % of the entire HF and number
of points to generate, and then will export these point coordinates in
an array of 3d coordinates. You then use the array in a while a loop to
translate your choosen "TheTHING" to their respective locations. 
   Since the program knows where each elevation point is along the grid
it's output gives very accuarate placement of "TheTHING" or group of
"TheTHINGS". There is also an option at the time of the export where
it will provide a sample Pov script for the proper use of the while
loop in conjunction with the array to "TheTHING" to their final matching
positions along the topography of the height field.
  The export points feature is a somewhat limit function in that is is not
constrained to a selectable area rather it is ditributed across the entire
grid based upon the percentages you choose in the setup fields. The only
constraing option that I am aware of is you may choose an elevation cutoff
point that works much the same as the water level does in Pov. This way
you will have "TheTHING" restricted to points that are higher than that
elevation you choose as the demarcation line.
  There are other tools in the program that make it possible to measure
a point on the field but I wouldn't try this for more than a hand full
of objects since as far as I know you would have to copy the information
down and use it later when you set up your scene file. It would be tedious
with many objects invoved, but also may prove invaluable for placing a
couple of buildings on a hill, or a string of fence posts up a slope,
that other wise would take way too much trail and error to get
positioned right otherwise.

Leveller may be found at: http://www.daylongraphics.com/

His ISP is giving him problems with access right now due to equipment
changes. If it shows up missing or inactive try back in a couple days
and it should be there.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Robert J Becraft wrote in message <36C### [at] aolcom>...
>
>I would like to see something that allowed me to define a heightfield as a
>CSG, then using that as a target, create a function that given an X,Z
>coordinate in the heightfield would return the Y value for that point.
>This out of all the modifications that could be made to POV would be the
>greatest improvement in my mind.
>
>Imagine,all those people who have contributed grass renders... you take
your
>grass stalks and place them approriately on a gently rolling heightfield.
>Every one of them is placed at the right height irregardless of the point
on
>the heightfield it is generated.
>

Unless you are opposed to using an unofficial compile of POV, I suggest you
get the Superpatch. It has a trace() function that does what you want.
Example:
trace(MyHeightField,StartPoint,Dir,Normal);

This traces a ray from StartPoint in direction Dir and if MyHeightField is
hit, returns the intersection point. It also stores the surface normal of
that point in a pre-declared identifier "Normal", if it's provided.
I have found this function incredibly useful; my "shaggy" images were made
using it.

Margus

Post a reply to this message

Have to come in here a bit.
I've spent some time coding(a few years, more or less) and I have tried
most of the languages avaiable, Mostly the larger common ones. As I have
a friend, who is Asm addicted, as well as a C-coder, I took part of his
examples. using the borland c compiler, not the best, not the worst, he
made a simple algorithm to change a string in certain ways, first in C,
then in asm. After that, we peeked at the asm output that the compiler
made. it was some 400% larger both in code and instrucioon wise.(don't
ask details, I don't remember).

This gives, together with most specific ideas, that a smaller
function/code-pice is very much more effective in ASM than In any
language, and that is where asm code would give the best results, in
smaller, commonly used functions.


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

I love your heightfield idea, and I have another.
Why not make a heightfield function, but instead of taking an image as
the original object, take a texture or pigment statement. using a
image_map you get the old typpe heightfield, and using any other
pigment, you can loose one stage in hf useage procedure. (many of us
create our height_fields in pov)
Sure, the pigment will need some scaling in all directions to fit
nicely, but this can't be a trouble for the coder. Anyone catching my
idea ?




-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

A ine pice of asm coding :
http://www.algonet.se/~redhog/
He's currently coding a OS in asm. As far as I know he's already made
the multitasker....


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

portelli schrieb in Nachricht <36CD28A6.48AB9F3E@pilot.msu.edu>...
>It would become platform dependent.  I know that Sparc asm and MIPS asm
>are different.  The destination registers are in different places in
>notation I think.  I don't even know about Intel, isn't there just one
>register and the accumelator.  Yuck.  I like thre registers.

I think you're confusing the current PCs with the Apple ][ <g>.

A modern Intel CPU has more than one register and can use more than one
register to do calculations.

But of course, assembler is (most of the time) different on different CPUs.
--
Rudy Velthuis

Post a reply to this message

Again, check out the Superpatch. It can do a procedural height field, i.e.
it takes an ordinary POV texture instead of a bitmap.

Margus

Spider wrote in message <36CDACEB.3945631F@bahnhof.se>...
>I love your heightfield idea, and I have another.
>Why not make a heightfield function, but instead of taking an image as
>the original object, take a texture or pigment statement. using a
>image_map you get the old typpe heightfield, and using any other
>pigment, you can loose one stage in hf useage procedure. (many of us
>create our height_fields in pov)
>Sure, the pigment will need some scaling in all directions to fit
>nicely, but this can't be a trouble for the coder. Anyone catching my
>idea ?
>
>
>
>
>--
>//Spider
>( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
>#declare life = rand(seed(42))*sqrt(-1);
>
>

Post a reply to this message

Spider schrieb in Nachricht <36CDAD6D.3F026D07@bahnhof.se>...
>A ine pice of asm coding :
>http://www.algonet.se/~redhog/
>He's currently coding a OS in asm. As far as I know he's already made
>the multitasker....

Believe it or not... but when I was 20, I have coded a simple OS (16k ROM
based OS) for my Acorn BBC-B home computer once, because the one provided
with my double density floppy controller (Acorn only offered single density
then) had too many bugs. So I started writing one from scratch in
BBC-Basic-Assmbler (the assembler was integrated in the Basic and could for
instance use Basic functions as macros and special integer variables as
compile pointers). As memory was a problem, I had to chain several files
together to compile to "upper RAM" (in ROM space) directly. This was
hand-optimised 6502 code. Of course it was not multi-tasking. It was used by
many friends who had the same controller.

A language like Inprise Borland Object Pascal and the component library VCL
uses assembler in time-critical parts (sorting, string functions) or in
parts, where a call couldn't easily be faked using high level Pascal
(because something like non-standard stack handling is required). I've
however seen one example, where optimized Pascal code was *faster* than the
original hand-optimized assembler routine. This was also a string function.
It was the improved algorithm which did the trick.

--
Rudy Velthuis

Post a reply to this message