"LanuHum" <Lan### [at] yandexru> wrote:
> "Mr" <nomail@nomail> wrote:
>
> >
> > Yes, I understand, and this time I totally agree with you. that is why I love
> > POV-Ray: maturity.
> >
> > Blender is relatively young. its community sometimes suffered from what we call
> > "jeunisme" in french, the tendancy to believe that what is new is necessarily
> > better. that's why most blenderheads rushed to Mitsuba, Luxrender, Yafaray,
> > Kerkythea, Thea, Octane, Aqsis...  etc, without ever considering to help
> > modernize and integrate POV-Ray, simply because "it is old". LuxRender has had
> > up to 16 enthusiast developers, Cycles is driven almost full time by one of the
> > most professional, skilled an experienced developers available.
> > However four/five years or more after their creations, POV-Ray still offers some
> > functionality unavailable to them (Continue Trace) and has caught up with some
> > of its new candies (Real Time stochastic Rendering) to be fair, POV-Ray still
> > misses some features but these give no other difference in the final result than
> > rendering time (this could be debatable, for the way some features such as
> > spectral rendering would leverage more ressources and help overcome some POV-Ray
> > "crashing points", do show if you try the most extreme refractive caustics
> > scenes in POV-Ray and compare them with LuxRender results at the time of writing
> > this)
> >
> > Because some of the Blender friendly external renderers and their exporters'
> > development kept drying out. The solution chosen was to nest the development of
> > the rendering engine inside the Blender Foundation to harvest all of the
> > community energy and feedback. This DID work, and Cycles development has been
> > blazingly fast and did not die. We could consider that with the manpower used in
> > all of these renderers povray 4 would already be there, but it would be like
> > considering you could put a town in a bottle if only every house was smaller.
> >
> > Probably you are working in an area of blender (the nodes) that is less stable
> > than the rest now, the basic material and render API used to change often too
> > but has now stabilized. Here again, being in official addon repository has
> > helped, because developers helping to propagate their api changes themselves
> > made them hold their horses. If you really want to keep a separate branch, then
> > probably you will have more luck with developing other operators while you wait
> > for this stabilisation, such as POV-Ray importers, and tools.
>
> Thanks for understanding and explanation!
>
> > For instance we
> > could use a system of  locked primitives without edit mode and just pov
> > parameters, if possible: creating a cube would create a mesh cube, torus the
> > same, but the idea would be that at no point you could change the topology, only
> > the size, radius, etc. these would be sexy to the blender community because no
> > other renderer offers perfectly smooth shapes, except Aqsis and there is to my
> > knowledge no Blender interface well taylored specifically for them.
>
> You could see that the early version of my exporter had such opportunity:
> object write as... (supertorus, superellipsoid, sphere, cone)
> I kept source code and I will transfer it to the new version.
> In the Blender we create mesh simulation, but we broadcast only a matrix, and we
> represent object as povray shape

Yes it was a good path to explore, but I think it's important that mesh topolgy
gets locked for these specific object types so that user can't break the system,
right?


Also, I insist, for us to keep the motivation, it's important that we try to do
actual pictures, because that will make at least one user giving the most direct
kind of feedback ;-)

Post a reply to this message