Chris Cason <del### [at] deletethistoopovrayorg> wrote:

> > There are job-search sites, and perhaps there are types of job headings that
> > requests for developers could be listed under.  A shiny ray-traced graphic or
> > two and a link to the HOF could pique someone's interest.
>
> I considered reaching out to some of my contacts in .edu-land to see if
> I could get some interested students.

Paul Bourke certainly seems to have enjoyed POV-Ray, and Apparently there are
still some professors out there who send their students this way to dabble in
the black art of CPU raytracing.

> The
> person really needs to genuinely be interested in POV-Ray itself, and if
> they are then it's likely they'll approach us (or we'll hear of some
> work they've been doing).

They do.  But they also need to be aware of POV-Ray at all, and there at least
needs to be the "FREE CANDY" sign on the van in the parking lot to entice them
to come over and look...   ;)
If you and others are clearly aware of what a CPU raytracer can do that
GPU-software _can't_ - then making that list of things available to us and any
potentially interested parties would go far.

You have all of these important pieces of detailed factual data that anyone
considering assisting you needs.   We need them to be instantly available and
easily accessible so that in the 5 minutes I'm not being distracted by any of 12
things and I'm right there in a news feed where I could make the plug for
POV-Ray, I can just pull whatever I need up, copy, paste, done.
Having such lists of things right on the front web page also addresses the
concern that POV-Ray can appear quite stagnant, even though it does have more
usage than it appears to.

> Secondly, in depth-work on povray can be *hard* to get right. Sure, it's
> easy to make tweaks here and there but to really work on the program as
> a whole you need to have a solid grasp on how everything works together
> as adding what appears to be a simple feature has the potential, in some
> cases, to do really unexpected things *if* you don't know how it works
> as a whole. To get a developer up to speed on the guts as a whole takes
> time. Plus whoever it is needs to be really competent with C++ and
> unmanaged languages (by which I mean having to do your own memory
> management).

Yes - I've sifted through the source code on a number of occasions, payed
attention to clipka, and I understand what you mean.

> That said, I can see where we *could* use a student or less-experienced
> developer who wanted to round out their background a bit: it would be
> great to have someone formally document the inner workings in a detailed
> form (i.e. at least enough so that someone who doesn't know how
> everything fits together could read it and understand). This would make
> getting up to speed on the codebase for anyone who wants to do so a fair
> bit easier and would also help in splitting it into bits for the 4.0
> rewrite.
>
> But that's a lot of work ...

Yes.   But something that we can get started and work on, stepwise.


> Many people seem to think GPU raytracing is the
> future and software renderers are dead but simply don't understand that
> at this point GPU's are still incapable of the level of precision and
> generic applicability that a fully primitive-based renderer is, and I
> don't see that changing anytime soon (as there's no real need to).

vide supra.

> But you know what? Despite the fact
> this thread has been a bit, um, rowdy, it's shown me that there's still
> a bunch of people who do care and has helped improve my feelings about
> the whole thing. I might even enjoy getting stuck back into the code,
> time will tell.
>
> -- Chris

Thanks again Chris.
Gotta go do the things.  bbl

Post a reply to this message