 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dre wrote:
> <snip>
>> I'm not sure that the time it takes to parse large sets is really worth
>> it. See the image I posted in p.b.i.:
>>
http://news.povray.org/povray.binaries.images/thread/%3C4c6d67d5%40news.povray.org%3E/
>>
>> It took 23 minutes, 36 seconds to parse. Out of the 50,000 tests I gave it
>> to perform, only a mere 3,065 succeeded.
>
> This is the exact problem I ran into when coding the same sort of thing. My
> code works also but it has a very high miss rate, very low success rate and
> it also takes ages to parse.
Yeah, it's really horrible. POV's SDL wasn't meant to be quick at
everything...
So far, my C++ implementation is very fast, for not being coded with ASM
and all. I was able to implement a few speedups, like not using
sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
array and picking from that.
But now I'm stuck on trying to convert an int to a char, and
vice-versus. It always comes down to something like that with C :( To
make a utility like this useful, the user need to be able to change
certain settings... This one might take awhile.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> "stbenge" <myu### [at] hotmail com> schreef in bericht
>> It took 23 minutes, 36 seconds to parse. Out of the 50,000 tests I gave it
>> to perform, only a mere 3,065 succeeded.
>
> That seems indeed to be the trade-off of this method. :-(
The C++ version works very well, and it's super-fast, but now I need to
make a GUI...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> But now I'm stuck on trying to convert an int to a char, and
> vice-versus. It always comes down to something like that with C :( To
> make a utility like this useful, the user need to be able to change
> certain settings... This one might take awhile.
Just in case somebody was going to reply to this... I can now use chars
as integers, but I can't make it work for a text box. So far, my
attempts to place a number as text into a text field produce nothing,
though the code compiles...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> Just in case somebody was going to reply to this... I can now use chars
> as integers, but I can't make it work for a text box. So far, my
> attempts to place a number as text into a text field produce nothing,
> though the code compiles...
Never mind, I think I've got it working now :\
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: how to prevent overlapping random objects?
Date: 21 Aug 2010 03:07:53
Message: <4c6f7b49@news.povray.org>
|
|
|
| |
| |
|
|
"stbenge" <myu### [at] hotmailcom> schreef in bericht
news:4c6ee306$1@news.povray.org...
> Thomas de Groot wrote:
>> "stbenge" <myu### [at] hotmailcom> schreef in bericht
>>> It took 23 minutes, 36 seconds to parse. Out of the 50,000 tests I gave
>>> it to perform, only a mere 3,065 succeeded.
>>
>> That seems indeed to be the trade-off of this method. :-(
>
> The C++ version works very well, and it's super-fast, but now I need to
> make a GUI...
Come on, Sam! You can do it! You rule! :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> "stbenge" <myu### [at] hotmailcom> schreef in bericht
> news:4c6ee306$1@news.povray.org...
>> Thomas de Groot wrote:
>>> "stbenge" <myu### [at] hotmailcom> schreef in bericht
>>>> It took 23 minutes, 36 seconds to parse. Out of the 50,000 tests I gave
>>>> it to perform, only a mere 3,065 succeeded.
>>> That seems indeed to be the trade-off of this method. :-(
>> The C++ version works very well, and it's super-fast, but now I need to
>> make a GUI...
>
> Come on, Sam! You can do it! You rule! :-)
It's getting close... got the (simple) GUI, now I need to tackle
vector.h, which will probably be the easy part. Thanks for the
encouragement! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yeah, it's really horrible. POV's SDL wasn't meant to be quick at
> everything...
>
> So far, my C++ implementation is very fast, for not being coded with ASM
> and all. I was able to implement a few speedups, like not using
> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
> array and picking from that.
>
> But now I'm stuck on trying to convert an int to a char, and
> vice-versus. It always comes down to something like that with C :( To
> make a utility like this useful, the user need to be able to change
> certain settings... This one might take awhile.
What's the fastest? sqrt(x*x+y*y) or sqrt(x^2+y^2)
In POV-Ray SDL, the second, as sqrt(pow(x,2)+pow(y,2)), is faster. Don't
know how it compare in C/C++ or other compiled languages.
May be worth testing.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So far, my C++ implementation is very fast, for not being coded with ASM
> and all. I was able to implement a few speedups, like not using
> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
> array and picking from that.
You're doing a radius comparison, right? You probably don't need to take
a square root.
- Slime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> So far, my C++ implementation is very fast, for not being coded with ASM
>> and all. I was able to implement a few speedups, like not using
>> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
>> array and picking from that.
>
> You're doing a radius comparison, right? You probably don't need to take
> a square root.
No, I'm setting specific radii (in pixels) and testing against a 2D
array using a brute-force method. In POV I was doing radius comparisons.
At any rate, I'm only having to do the sqrt(x*x+y*y) calculation 128*128
times when the program starts, to fill an array. It's like 1/4 of a
cylindrical pigment, and is the maximum circle radius. It's a drop in
the bucket, really.
Of course, with today's computers I can afford to be so wasteful. Not
that my program is running at record speeds or anything. Maybe if I knew
assembly language... :(
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
>> Yeah, it's really horrible. POV's SDL wasn't meant to be quick at
>> everything...
>>
>> So far, my C++ implementation is very fast, for not being coded with ASM
>> and all. I was able to implement a few speedups, like not using
>> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
>> array and picking from that.
>
> What's the fastest? sqrt(x*x+y*y) or sqrt(x^2+y^2)
> In POV-Ray SDL, the second, as sqrt(pow(x,2)+pow(y,2)), is faster. Don't
> know how it compare in C/C++ or other compiled languages.
>
> May be worth testing.
>
> Alain
Hmm, I was not aware that pow(n,2) was faster than n*n. I'll keep it in
mind next time the issue comes up. In my program, sqrt(x*x+y*y) is only
called at the very beginning to fill a small array.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
