POV-Ray : Newsgroups : povray.general : Algorithm-approach to eliminate intersections... Server Time
6 Aug 2024 06:21:49 EDT (-0400)
  Algorithm-approach to eliminate intersections... (Message 14 to 23 of 23)  
<<< Previous 10 Messages Goto Initial 10 Messages
From:
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 21 Jun 2002 08:24:20
Message: <fk66hug4es9vkml6048kp4gp94p6633q5e@4ax.com>

wrote:
> #declare Count=1000;

With #declare Count=1500; it reached limit of recursion but it can be simple
avoided with smart script :-)

ABX


Post a reply to this message

From:
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 21 Jun 2002 08:32:38
Message: <d476hu0rjtm4872ohkmfrhr66ohfu4ucvv@4ax.com>

wrote:
>  #local X=Interpolate(rand(Generator),0,1,Min.x,Max.x,1);
>  #local Y=Interpolate(rand(Generator),0,1,Min.y,Max.y,1);

and of course above could be much speed up with

  #local X=adj_range(rand(Generator),Min.x,Max.x);
  #local Y=adj_range(rand(Generator),Min.y,Max.y);

ABX


Post a reply to this message

From: Samuel Benge
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 21 Jun 2002 13:36:22
Message: <3D136411.1020006@caltel.com>
Tim Nikias wrote:

> I'll think about it, but on the other side, I'm a purist... ;-)
> 

I justify using external scene creation utilities by:
1. seeing just how long a scene can take to render if you use POV to 
figure out complex coordinates for vector coordinates and objects such 
as meshes
2. realizing that POV supports all kinds of file types for a reason

I'm afraid if I start down the road of absolute purism (a redundant 
statement, I know :) I'll be forced to try and take the brute-force 
apporach to everything, making the render times skyrocket.
I guess I like to take shortcuts if it doesn't drastically reduce the 
quality of the scene!

-- 
Samuel Benge

sbe### [at] caltelcom


Post a reply to this message

From: John VanSickle
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 21 Jun 2002 17:49:42
Message: <3D139F8B.9CE6B241@hotmail.com>
Tim Nikias wrote:
> 
> Nontheless, I'm thinking how I can simplify the method of
> counter-checking every new object with ALL objects
> that were formerly generated. I do know of the subdivision
> method, i.e. creating several blocks and only checking in
> those and the nearest blocks, but are there any different
> approaches, like sorting all positions somehow?

Make a big two-dimensional array.  Initialize each value to a negative
number, equal to the radius of the largest object you'll be placing.

Map each object to a position in this array.  Fill in this position with
the radius of the object, plus the amount of whatever
minimum clearance you want between objects.  Fill in the surrounding
spaces with values that decrease from this amount in a linear fashion,
depending on the distance represented between the two; except that
a higher value is never replaced with a lower one.

For each object placed thereafter, check the position in the array
that maps to the center of the object to be placed; if the value at
that spot, plus the radius of the object, is greater than zero, the
object will overlap another; pick another spot.

The array doesn't need to be that precise.

Can't figure out how to tell when the array is full, other than a
brute-force check of the entire array.

Regards,
John


Post a reply to this message

From: Apache
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 22 Jun 2002 00:50:28
Message: <3d140214$1@news.povray.org>
I agree. I started experimenting with cloth particle systems using SDL, but
it was way too slow. I ported the stuff to perl and later on I decided to
use C, because that language is pretty fast stuff.
And maybe I'm a purist myself, because I want to create all stuff myself
instead of using 3D Studio or Maya and plug-ins.

--
Apache
POV-Ray Cloth experiments: http://geitenkaas.dns2go.com/experiments/
Email: apa### [at] yahoocom
ICQ: 146690431


Post a reply to this message

From: Tim Nikias
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 22 Jun 2002 07:17:16
Message: <3D145CBD.3F8E7EBF@gmx.de>
You're both right. Using C# to write own programs is no
act against purism... ;-)

But I like to think of POV-Ray like I think of JAVA:
Once the script is finished, anybody who has POV-Ray,
and is thus the probably only person interested in the
script I've written for POV-Ray (why should a 3D-Gamer
be interested in a non I/O particle system, when my
methods are of no use to him?), can actually run it.
With C#, I'd probably have to compile it for Unix, Linux,
Mac and whatnot (I'm not too sure about all those, but we
all know that different systems aren't fully compatible)...

That's why I like to keep my code in POV-SDL, though I do
think that there could be some way to manage to get the
source-codes compatible. Somehow. Hope so at least.



Apache wrote:

> I agree. I started experimenting with cloth particle systems using SDL, but
> it was way too slow. I ported the stuff to perl and later on I decided to
> use C, because that language is pretty fast stuff.
> And maybe I'm a purist myself, because I want to create all stuff myself
> instead of using 3D Studio or Maya and plug-ins.
>
> --
> Apache
> POV-Ray Cloth experiments: http://geitenkaas.dns2go.com/experiments/
> Email: apa### [at] yahoocom
> ICQ: 146690431




--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde


Post a reply to this message

From: Tim Nikias
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 22 Jun 2002 07:22:41
Message: <3D145E02.E3826D7F@gmx.de>
You're system keeps track of how much of the ground
is occupied. Its a neat idea, though when combined with
slopes, its hard to predict how much space you actually
have availabe.

But I'll keep it in mind for future projects... Thanks!


John VanSickle wrote:

> Tim Nikias wrote:
> >
> > Nontheless, I'm thinking how I can simplify the method of
> > counter-checking every new object with ALL objects
> > that were formerly generated. I do know of the subdivision
> > method, i.e. creating several blocks and only checking in
> > those and the nearest blocks, but are there any different
> > approaches, like sorting all positions somehow?
>
> Make a big two-dimensional array.  Initialize each value to a negative
> number, equal to the radius of the largest object you'll be placing.
>
> Map each object to a position in this array.  Fill in this position with
> the radius of the object, plus the amount of whatever
> minimum clearance you want between objects.  Fill in the surrounding
> spaces with values that decrease from this amount in a linear fashion,
> depending on the distance represented between the two; except that
> a higher value is never replaced with a lower one.
>
> For each object placed thereafter, check the position in the array
> that maps to the center of the object to be placed; if the value at
> that spot, plus the radius of the object, is greater than zero, the
> object will overlap another; pick another spot.
>
> The array doesn't need to be that precise.
>
> Can't figure out how to tell when the array is full, other than a
> brute-force check of the entire array.
>
> Regards,
> John




--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde


Post a reply to this message

From: Apache
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 22 Jun 2002 17:21:20
Message: <3d14ea50$1@news.povray.org>
All my C/C++ code is ANSI, so it compiles on all platforms without too much
tweaking.

--
Apache
POV-Ray Cloth experiments: http://geitenkaas.dns2go.com/experiments/
Email: apa### [at] yahoocom
ICQ: 146690431


Post a reply to this message

From: Tim Nikias
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 23 Jun 2002 05:21:16
Message: <3D15930C.3356B629@gmx.de>
Still needs a C++ compiler, not everyone has one... When using
POV, everyone has POV. When using POV, not everyone has
C++. That was the point I would put most emphasize on.

You're right though.

Apache wrote:

> All my C/C++ code is ANSI, so it compiles on all platforms without too much
> tweaking.
>
> --
> Apache
> POV-Ray Cloth experiments: http://geitenkaas.dns2go.com/experiments/
> Email: apa### [at] yahoocom
> ICQ: 146690431




--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde


Post a reply to this message

From: Warp
Subject: Re: Algorithm-approach to eliminate intersections...
Date: 23 Jun 2002 08:37:57
Message: <3d15c125@news.povray.org>
Apache <apa### [at] yahoocom> wrote:
> All my C/C++ code is ANSI, so it compiles on all platforms without too much
> tweaking.

  C/C++ code conforming to the ANSI standard doesn't necessarily mean
that it will work in all platforms (or even in more than one specific
platform).

  For example there's nothing against the standard in the following code:

void PutPixel(int x, int y, unsigned char color)
{
  unsigned char* screen = (unsigned char*)0xA0000;
  screen[x+y*320] = color;
}

  However, in most systems it will just cause a segmentation fault, and even
if it doesn't, it certainly will not work as expected.

  Also some things cause surprises among the unaware coders:

char table[10];
int* ptr = (int*)(&table[1]);
*ptr = 5;

  This works ok in some systems (eg. Intel) but in most RISC processors it
causes a bus error (ie. the program crashes).

  Conforming to the standard is not enough to make portable code.

-- 
#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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.