Rune wrote:
> 
> It's not a big problem. Under most circumstances, none or very few
> particles fall through the surface. Wouldn't function-based environments
> require the user to specify the environments as functions? 

Right, but it would be much more robust compared to your method and you
won't need something like 'particle_bounceoffset' and 'particle_killobj'
which also makes things easier.

> > - i have not checked the code but from what you
> > write in 'Inner workings' gravity is added to
> > the position ("Each particle is moved by it's
> > current velocity (current location minus last
> > location) plus gravity (for example -y)") while
> > it should be added to the velocity in fact.
> 
> That would be true if I had one variable for location and one for
> velocity, and then could calculate the new location based on this. But
> in fact I have one variable for the old location and one for the new
> location, and then I can derive the velocity from this. So when I add
> gravity to the new location but not the old, then it's the same as
> adding gravity to the velocity.

Not really, but a look at the source reverals that you seem to do it the
right way.  Your formula (as far as i can see) is:

new_position = old_position + time_step * old_velocity + time_step^2 *
acceleration 

which can be derived from the formula of classical explicit first order
integration method:

new_velocity = old_velocity + time_step * acceleration
new_position = old_position + time_step * old_velocity

if we put in new_velocity for old_velocity which does not change anything
fundamental, the method is probably still convergent.

But notice the difference between 'time_step^2 * acceleration' and
acceleration itself (in your case gravity). 'time_step' is quite small.  

> [...]
> 
> Well, it's important for me that people don't make profit on my work;
> perhaps more important than how great success my tool gets.

In general?

You contributed to the POV-Ray 3.5 include files although those are
allowed to be used commercially.

> Besides, if
> people want to make profit on it, they can either make an arrangement
> where they buy a license from me, or if they are going to make very
> minor profits only, they can obtain a permission from me to use it for
> free anyway.
> 
> Maybe I should make this part in bold:
> "If you would like to do something with it that is not allowed according
> to the terms described here, you can always ask me for a special
> permission."

I think this is nearly obvious from what you write in your terms, but most
professionals (and also ambitious hobbyists) like clear conditions and
don't want to depend on your generosity when they start using your tool. 
If you think your include file is worth some payment for being used
commercially you should clearly state that in the terms of use.  Something

commercial usage contact me for receiving the current price list".

> Or maybe I should rewrite the terms of use completely. Dunno. I'm glad
> to discuss them and to get input and thoughts on them.

Well, i think the reasons for you creating such restrictions are somewhat
understandable but i somehow doubt they have the intended effect.  For me
knowing my products are used by a lot of people, no matter if for making
profit or not, seems more rewarding than knowing nobody can legally make
money using my tools.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message