My particle system is finally released! You can use it POV-Ray 3.5 to
create all sorts of effects, like water, smoke, fire and sparks. With a
generic and non-specialized engine, the system makes it easy to
customize the simulation to a wide range of uses. The package comes
complete with include files, documentation, and several sample scene
files that makes it easy to get started. You can download the system and
also see animations of all the sample scene files here:
http://runevision.com/3d/include/particles/

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> My particle system is finally released! You can use it POV-Ray 3.5 to
> create all sorts of effects, like water, smoke, fire and sparks. With a
> generic and non-specialized engine, the system makes it easy to
> customize the simulation to a wide range of uses. The package comes
> complete with include files, documentation, and several sample scene
> files that makes it easy to get started. You can download the system and
> also see animations of all the sample scene files here:
> http://runevision.com/3d/include/particles/
> 

Nice. And congratulations for finally finishing it. :-)

I have not tried it yet but the example animations look good.

A few comments:
 
- from what you write in the documentation about the collisions i conclude
you have not solved the 'particles penetrating the surface'-problem.  You
might try function based environments like i'm using for my mechanics
simulations.
 
- 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.

- i am somewhat astonished about your license conditions.  I understand if
you don't want others to modify your tool and redistribute changed
versions but requiring everyone to contact you before publishing a
picture/animation using your file seems a bit exaggerated.  

Forbidding to use your include file for producing commercial work is to
some extent understandable - you don't want others to make profit with
something you put a lot of work into and none the less give away for free,
but on the other hand such a restriction will almost surely prevent a
great success of your tool since a lot of people will refrain from using
it from the beginning with such a restriction.

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

Christoph Hormann <chr### [at] gmxde> wrote in
news:3DB1D68A.499B34D2@gmx.de 

> - from what you write in the documentation about the collisions i
> conclude you have not solved the 'particles penetrating the
> surface'-problem.  You might try function based environments like i'm
> using for my mechanics simulations.

Hellow,
little OT suggestion - how about changing POV work philosofy to get a big 
hmm calculations utility, that can work togeather with external programs.

Now schemat is like :
* pov parses scene
* pov is doing some pre-calculations like photons
* pov is rendering scene lines 0..height

I suggest something like :
a) pov starts and :

b) Now pov works as hmm some kind of server (not web server ofcourse :P)
he keeps in memory all nesesary data, and response to following possible 
requests :
* commands 
  - load and parse scene "..."
  - unload current scene (dealloc)
  - quit
* render 
  - render pixel
  - render sample (for AA)
  - render line
  - render area
* scene phisics informations
  - is point (x,y,z) inside object called "..."
  - intersection (x,y,z) in direction (X,Y,Z) of object "..."
  - normal of object "..." in point (x,y,z)
  - color of object in (x,y,z)
    - color due to diffuse
    - ... refelction
    - photons
    - etc

From technical side, possible comunication pipes could be i.e.:
- DDL sharing memory in Windows
- pipes in Unix/Linux ? (i'm newbie in this topic)
- files (in any OS, but it may be slow, unless files are i.e. in RAM disc)
- some TCP/IP protocol ? it would be realy greate and will allow very nice 
cluster rendering

Possible usage :
- cluster rendering
- additional editors / front-ends
- external programs like phisicla smulations


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

I suggest you put the documentation on the actual web page (linked from it,
that is). I'd personally like to skim the documentation and see what the
syntax is like before I download and unzip a file, y'know?

That said, this looks cool enough that I'm going to do so anyway. =)

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Christoph Hormann wrote:
> Nice. And congratulations for finally finishing it. :-)

Thank you. :)

> - from what you write in the documentation about
> the collisions i conclude you have not solved the
> 'particles penetrating the surface'- problem.
> You might try function based environments like
> i'm using for my mechanics simulations.

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? As simplicity
is one of the major goals in my system, I want the environment to simply
be an object, as that is much easier to control, and more intuitive too.

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

> I understand if you don't want others to modify
> your tool and redistribute changed versions but
> requiring everyone to contact you before publishing
> a picture/animation using your file seems a bit
> exaggerated.

Yes, it's a bit over the edge, I know. :/  I might change it. It's
mostly there because I really like to get contacted when people have
used my utilities for something...

> Forbidding to use your include file for producing
> commercial work is to some extent understandable
> - you don't want others to make profit with something
> you put a lot of work into and none the less give
> away for free

Exactly.

> but on the other hand such a restriction will almost
> surely prevent a great success of your tool since a
> lot of people will refrain from using it from the
> beginning with such a restriction.

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. 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."

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.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Slime wrote:
> I suggest you put the documentation on the actual
> web page (linked from it, that is). I'd personally
> like to skim the documentation and see what the
> syntax is like before I download and unzip a file,
> y'know?

Ok, I'll do that. :)

> That said, this looks cool enough that I'm going
> to do so anyway. =)

Thanks. :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Got it just now, thanks for all your effort put into it. Hopefully I'll be
able to learn how to use it.

I read the Terms Of Use thoroughly. I wouldn't have too much of a problem
with anything; except my own descriptions of things I do are often minimal
to none, at least when put on the www. But I need to work on that aspect
anyhow, as I tend to think in a closed-circuit fashion in which I expect
people will know already, or find out about POV-Ray and the things
surrounding it, and so need little told to them. That being stuff I might
put on the Internet anyhow, I guess because it's pictures not talk. Links to
a persons web site is a simple matter, so shouldn't be a problem.

You could be asking for hundreds of e-mails to answer, or maybe some trouble
with the more ignorant people (nothing personal, anyone). Just that I think
a lot of people only glance over such things, unless they are serious about
that aspect themselves to begin with. What I'm getting at is that there is a
lot of chance for misunderstandings amid it all. Unfortunately, I haven't
any suggestions about possible changes you might make. There's nothing real
paramount from my viewpoint.

Post a reply to this message

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

Christoph Hormann wrote:
> 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.

particle_bounceoffset is a single value that is very easy to tweak.
particle_killobj is used for completely different purposes, where you
intentionally wants object killed when they hit a specific object.

This can in no way be compared to the complexity it is to define any
given surface in the term of a function. With the object approach you
can have a CSG object with hundreds of primitives in it and make the
particles collide with it, or you can use a mesh object for that matter.
That is next to impossible with functions. I don't see why you seem to
think that it is such a great advantage to use function based
environments, if you compare the pros and cons.

> Not really, but a look at the source reverals that
> you seem to do it the right way.

Well, the description "inner workings" on the page should not be taken
as an accurate description with precise formulas. I think there are even
some things in my system which does not really correspond to that
description, because it's meant to explain the most basic concept only.

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

Yes, in general, but not without exceptions.

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

Yes. But that was not my own project, it was just a project I helped
with.

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

Yeah, I should do that...

> Well, i think the reasons for you creating such
> restrictions are somewhat understandable but i
> somehow doubt they have the intended effect.

Well, I intent to keep most of the restriction, but perhaps in a
different form.

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

I don't feel that way. But then, I have very little money myself, which
probably makes even worse the thought of other people making profit on
my work.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> [...]
> I don't see why you seem to
> think that it is such a great advantage to use function based
> environments, if you compare the pros and cons.

Because i have used it and it works very nicely.  Maybe just try it out
with some heightfield object (and an image_map function in comparison).  I
remember this flowing animation with two channels dividing and merging you
once posted,  this would be a nice test object.

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