On 18-6-2015 11:16, Mr wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>>
>> Why not start a separate branch on the POV-Ray newsgroups tree
>> (poray.tool.blender) like there exists one for Poser (povray.tools.poser)?
>>
>> --
>> Thomas
>
> This is a great idea. I did not dare to ask for this before because I felt it
> should come from POV-Ray users so that no one would feel like Blender is
> invasive or whatever. We do respect both communities and their singularities, I
> know a lot of POV users don't feel like they need any graphical interface to it,
> On the other hand, a lot of Blender users feel they ONLY need an interface and
> don't ever want to see a text file to procuce images.

Personally, I never felt Blender to be invasive. Both it and POV-Ray can 
very well coexist together and both can certainly profit from the 
exchange without being in competition as it were. From the POV-Ray users 
point of view there might be some apprehension towards an unfamiliar 
Blender GUI, although that has been hugely improved over the last years 
I must say. I believe the number of Blender-using POVers is steadily 
growing.

>
> LanuHum, myself and only one more user, all came to try and bridge both software
> because of the possibility the scene description language offered.

And that is sincerely appreciated. I think we should be patient; that 
no-man's-land still is unfamiliar territory to most.

>
> But as you see from lanuhum discouragement, there was little actual feedback. We
> do need a more proactive user community to encourage development. I tried to
> create a Blenderartists forum group but other than the said user, no-one ever
> posted many questions, feedback, and more importantly, very few images of their
> works in progress have been shown.

It seems that the Blender community has not (yet) discovered what can be 
won by using POV-Ray as a renderer. Maybe that is too soon and will 
happen when a full-fledged interface is available to them, i.e. beyond 
the beta stage.

>
> Here in the povray newsgroup we did receive warm encouragements, both LanuHum
> and I, So yes maybe a newsgroup section would help to fuel this handreaching
> effort in the long run. May I also suggest that image attachments be allowed for
> it to emulate through created imagery, be they
> beautyful or ugly :-)?

Imo, most interest will come from the POV-Ray users as Blender opens up 
a large array of possibilities to them. So, yes, I would put my cards on 
a newsgroup section which - while initially small - will gradually 
attract and seduce more people. I am interpreting what I see in my 
crystal ball of course ;-)

Maybe create povray.tools.blender and povray.tools.blender.images ?

I don't know how to initiate these groups. I suppose that is a question 
for Chris to answer in the first place.

-- 
Thomas

Post a reply to this message

On 18-6-2015 11:50, Mr wrote:
>
> Another thing I do when I'm sick of no-one understanding the great potential of
> a Blender/POV synergy: rather than totally give up, let's pause development and
> make sample materials or pictures! That's what people need to see to realise
> what our exporters can do!
>
>

Exactly so! I fully support this suggestion.

To Lanuhum: Don't let silence discourage you. I think more people than 
you think are interested, only most stay in stealth mode waiting for 
further developments.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 18-6-2015 11:50, Mr wrote:
> >
> > Another thing I do when I'm sick of no-one understanding the great potential of
> > a Blender/POV synergy: rather than totally give up, let's pause development and
> > make sample materials or pictures! That's what people need to see to realise
> > what our exporters can do!
> >
> >
>
> Exactly so! I fully support this suggestion.
>
> To Lanuhum: Don't let silence discourage you. I think more people than
> you think are interested, only most stay in stealth mode waiting for
> further developments.
>
> --
> Thomas

Thomas, Mr, thanks!
Not only silence discourage to me.
The community Blender is very strongly attached to the renderer of Cycles.
The Blender developers constantly create obstacles for those who wants to use
other renderers.
They constantly break Python API.
Now my exporter doesn't work with Blender-2.74.5.
Instead of development of the exporter I looked for the reasons which don't give
to the program to work.
I corrected, but lost nerves and time.

Users of Povray can help if provide source of a full Povray-scene which Cycles
won't be able to create. ( Either it is heavy, or it is difficult)
Well for a scene:
1. Peeling paint isosurface.
2. Colored glass with refraction caustics
3. Reflecting surfaces with reflection caustics.
4. Both: 2 and 3
5. Polygon to circle loft.
6. Boolean with spline-based objects.
7. difference{
sphere{} // or cylinder{}
cone{}
}
and so on...

If I have some samples of scenes, I will be able to adjust the exporter to
repeat it using Blender.
Independently I will long go.
But I go!  :)

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > On 18-6-2015 11:50, Mr wrote:
> > >
> > > Another thing I do when I'm sick of no-one understanding the great potential of
> > > a Blender/POV synergy: rather than totally give up, let's pause development and
> > > make sample materials or pictures! That's what people need to see to realise
> > > what our exporters can do!
> > >
> > >
> >
> > Exactly so! I fully support this suggestion.
> >
> > To Lanuhum: Don't let silence discourage you. I think more people than
> > you think are interested, only most stay in stealth mode waiting for
> > further developments.
> >
> > --
> > Thomas
>
> Thomas, Mr, thanks!
> Not only silence discourage to me.
> The community Blender is very strongly attached to the renderer of Cycles.
> The Blender developers constantly create obstacles for those who wants to use
> other renderers.
> They constantly break Python API.
> Now my exporter doesn't work with Blender-2.74.5.
> Instead of development of the exporter I looked for the reasons which don't give
> to the program to work.
> I corrected, but lost nerves and time.
>
> Users of Povray can help if provide source of a full Povray-scene which Cycles
> won't be able to create. ( Either it is heavy, or it is difficult)
> Well for a scene:
> 1. Peeling paint isosurface.
> 2. Colored glass with refraction caustics
> 3. Reflecting surfaces with reflection caustics.
> 4. Both: 2 and 3
> 5. Polygon to circle loft.
> 6. Boolean with spline-based objects.
> 7. difference{
> sphere{} // or cylinder{}
> cone{}
> }
> and so on...
>
> If I have some samples of scenes, I will be able to adjust the exporter to
> repeat it using Blender.
> Independently I will long go.
> But I go!  :)


Although I know why you say that, I can't let you say it. Because I did receive
a lot of help from Ideasman 42,  and mont29 (I don't know if they whish to see
their real names written or prefer the nicks) both are two of the main Blender
developers (under paid contracts for the Blender Foundation). Here is how the
help was provided: Every time the api Broke, Ideasman changed the script
himself, to adapt to the change. the POV-Ray exporter served as a testbead for
it so it's been updated up to now, and I had to change almost nothing myself for
the api changes! This is why it is vital for you to try and get your branche
able to merge back with the trunk, this way you can get pauses without seeing
your code is broken when you get back to work. it's collectively maintained.
Mont 29 speaks french and is the developer of the FBX exporter so he knows well
the connected fields of Blender data structure, file formats, geometry, export
process... For all these reasons and also because he's like the second circle of
coders while ideasman (generalist) and brecht(cycles developer) are the first
circle, I tend to go to him first when I'm stuck (even though he does have a lot
of work too, the first circle are kind of always on fire, (look at
#blender-coders IRC channels and you'll see what I mean) so you need to be extra
careful with what time you steal from them, especially because all of these guys
are very generous and responsive (mont29 included). but they do need to sleep.
The last to date example of mont29 contribution is with export of smoke
simulation: I had managed to export the smoke cloud but it appeared with some
transformations, he helped me settle this, previously he also helped to do the
instancing system, and so many other improvements.

However, to be fair, I should add that the project is one among many for them,
so we can only hope for so much from them, they are already providing their
maximum assistance.

Post a reply to this message

"Mr" <nomail@nomail> wrote:

>
>
> Although I know why you say that, I can't let you say it. Because I did receive
> a lot of help from Ideasman 42,  and mont29 (I don't know if they whish to see
> their real names written or prefer the nicks) both are two of the main Blender
> developers (under paid contracts for the Blender Foundation). Here is how the
> help was provided: Every time the api Broke, Ideasman changed the script
> himself, to adapt to the change. the POV-Ray exporter served as a testbead for
> it so it's been updated up to now, and I had to change almost nothing myself for
> the api changes! This is why it is vital for you to try and get your branche
> able to merge back with the trunk, this way you can get pauses without seeing
> your code is broken when you get back to work. it's collectively maintained.
> Mont 29 speaks french and is the developer of the FBX exporter so he knows well
> the connected fields of Blender data structure, file formats, geometry, export
> process... For all these reasons and also because he's like the second circle of
> coders while ideasman (generalist) and brecht(cycles developer) are the first
> circle, I tend to go to him first when I'm stuck (even though he does have a lot
> of work too, the first circle are kind of always on fire, (look at
> #blender-coders IRC channels and you'll see what I mean) so you need to be extra
> careful with what time you steal from them, especially because all of these guys
> are very generous and responsive (mont29 included). but they do need to sleep.
> The last to date example of mont29 contribution is with export of smoke
> simulation: I had managed to export the smoke cloud but it appeared with some
> transformations, he helped me settle this, previously he also helped to do the
> instancing system, and so many other improvements.
>
> However, to be fair, I should add that the project is one among many for them,
> so we can only hope for so much from them, they are already providing their
> maximum assistance.

Good!
Sorry!
Thus, Blender - free program which is constantly transformed.
Python API Blender is also created for all, but only the elite can use it.
We can ask them to help.
Well.
Nevertheless it is strange to ask for the help developers.
You can present such situation with Autodesk Maya or Cinema4D?
Someone bought Autodesk Maya today...
In a month there was an Autodesk Maya updating
The user can't write scripts any more, writes letters to developers.
Or...

But, why the Povray developers don't arrive as the Blender developers arrive?
In the example.pov file wrote 10 years ago:
sphere {0,1}
Today in the example.pov file write:
sphere {0,1}
And, it works.
That you told if today it is necessary to write
sphere {0,1},
tomorrow it will be necessary to write
sphere {1,0},
and the day after tomorrow it will be necessary to write:
{1,0} sphere
???
In the Blender such funny things - the law.


My nodes worked at 2.74
My nodes don't work in 2.74.5.
Changes happened, but functions didn't change.
Or is worse than that...
Yesterday I could rewrite class ShaderNodeTree, but today I can't...
Today I have to take away time from the developer to learn: "Why he made it? For
whom is it useful? How to fight against it?" :):):)

Sorry!
I don't know English.
Possibly, you didn't understand that I wanted to tell. :)

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
> "Mr" <nomail@nomail> wrote:
>
> >
> >
> > Although I know why you say that, I can't let you say it. Because I did receive
> > a lot of help from Ideasman 42,  and mont29 (I don't know if they whish to see
> > their real names written or prefer the nicks) both are two of the main Blender
> > developers (under paid contracts for the Blender Foundation). Here is how the
> > help was provided: Every time the api Broke, Ideasman changed the script
> > himself, to adapt to the change. the POV-Ray exporter served as a testbead for
> > it so it's been updated up to now, and I had to change almost nothing myself for
> > the api changes! This is why it is vital for you to try and get your branche
> > able to merge back with the trunk, this way you can get pauses without seeing
> > your code is broken when you get back to work. it's collectively maintained.
> > Mont 29 speaks french and is the developer of the FBX exporter so he knows well
> > the connected fields of Blender data structure, file formats, geometry, export
> > process... For all these reasons and also because he's like the second circle of
> > coders while ideasman (generalist) and brecht(cycles developer) are the first
> > circle, I tend to go to him first when I'm stuck (even though he does have a lot
> > of work too, the first circle are kind of always on fire, (look at
> > #blender-coders IRC channels and you'll see what I mean) so you need to be extra
> > careful with what time you steal from them, especially because all of these guys
> > are very generous and responsive (mont29 included). but they do need to sleep.
> > The last to date example of mont29 contribution is with export of smoke
> > simulation: I had managed to export the smoke cloud but it appeared with some
> > transformations, he helped me settle this, previously he also helped to do the
> > instancing system, and so many other improvements.
> >
> > However, to be fair, I should add that the project is one among many for them,
> > so we can only hope for so much from them, they are already providing their
> > maximum assistance.
>
> Good!
> Sorry!
> Thus, Blender - free program which is constantly transformed.
> Python API Blender is also created for all, but only the elite can use it.
> We can ask them to help.
> Well.
> Nevertheless it is strange to ask for the help developers.
> You can present such situation with Autodesk Maya or Cinema4D?
> Someone bought Autodesk Maya today...
> In a month there was an Autodesk Maya updating
> The user can't write scripts any more, writes letters to developers.
> Or...
>
> But, why the Povray developers don't arrive as the Blender developers arrive?
> In the example.pov file wrote 10 years ago:
> sphere {0,1}
> Today in the example.pov file write:
> sphere {0,1}
> And, it works.
> That you told if today it is necessary to write
> sphere {0,1},
> tomorrow it will be necessary to write
> sphere {1,0},
> and the day after tomorrow it will be necessary to write:
> {1,0} sphere
> ???
> In the Blender such funny things - the law.
>
>
> My nodes worked at 2.74
> My nodes don't work in 2.74.5.
> Changes happened, but functions didn't change.
> Or is worse than that...
> Yesterday I could rewrite class ShaderNodeTree, but today I can't...
> Today I have to take away time from the developer to learn: "Why he made it? For
> whom is it useful? How to fight against it?" :):):)
>
> Sorry!
> I don't know English.
> Possibly, you didn't understand that I wanted to tell. :)


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

Post a reply to this message

"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

Post a reply to this message

"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

"Mr" <nomail@nomail> wrote:
> 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 ;-)

Yes, well. :)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 04.06.2015 um 23:20 schrieb LanuHum:
> > Work on the project is stopped.
> > The repository is removed.
> > All thanks!
>
> You're abandoning your work? Why?

We continue!
:) :) :)

Post a reply to this message

Attachments:
Download 'lathe_new.blend.jpg' (241 KB)

Preview of image 'lathe_new.blend.jpg'