The advantage of well-documented code is not only
that its a benefit for others, but also, that you may understand
someday later how you did it, and what you did.

But true, include-files aren't used widely. The problem is:
what do POVers want and need?
Trees and plants, hence the widespread use of TomTree
and MakeTree etc. But particles? How often does a standard
user really need them?
And how often does he need more complicated simulations
with particles?

I'll still do Include-Files though, well documented, with Help
and all. I've found my own help-files pretty useful at times
where I return to an include-set after a long absence. And
perhaps someone does make use of them at some point...

But its good to know that you'll still be in the newsgroups,
you've been of good help, and I'd miss that.

But what about your walking system? Finish that one and
release it, or not?

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights


> > Yeah, it should be possible, but there's more work
> > required than just adding a few lines...
>
> Yeah, it was mostly said in fun... :)
>
> > For my next project involving particles, I plan
> > on doing a massive I/O project, where particles
> > may even be given away from a system into an
> > external file, where a different system might
> > look for it and do things with it. This should
> > make a wide variety of effects possible, where
> > different effects are done by smaller
> > include-files. Also, I could achieve effects
> > much more defined to a certain topic, e.g. in
> > a certain area, particles attract each other,
> > in a different one, a particle gets split into
> > two different ones, etc.
>
> Yeah, that would be interesting. For my system, I decided to draw the
> line a specific place. I wanted to have my system have full support for
> looping animations, and if other features were incompatible with that,
> then I didn't want to implement them. I may sound like a odd feature to
> put so much focus on, but its because the looping support actually is
> rooted deep in the entire way the system is coded.
>
> The fact that the system is coded this way also makes it efficient for
> rendering animations in several passes. The simulation don't have to be
> calculated all from the beginning, but only for as long back as a
> particle lives. All particles that are dead at the beginning frame of
> the animation have no effect on the current state, so they are
> disregarded completely.
>
> The main feature incompatible with looping is particle interaction, so
> my system has no support for that at all. That puts a great restriction
> on my system, but as I said, that's where I chose to draw the line.
>
> Your future particle system project sounds interesting. I've considered
> a similar project, but I don't think I'll do it after all. After my last
> particle system, I've become a bit tired of making large, generic,
> user-friendly and well-documented include files. It's rewarding in the
> end, but it's a whole lot of work, and given that the POV-Ray userbase
> of users who are both able to and willing to use such advanced include
> files is pretty small, I've found that I don't feel it's really worth it
> (for me). It's good to know though, that there are others to take over!
> ;)
>
> In the future I probably will make smaller include files for my own use,
> which are very good at performing a very specific task, but which are
> not very generic, nor user-friendly, and probably not documented at
> all... ;) That will probably save 80% of the workload! I intent to be
> more of a programming artist than a developer...
>
> 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
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message