"Maetes" <nomail@nomail> wrote:

>
> Or I will try the "B-Thing".
>
> Ma

Please do ! Our POV-Ray addon needs feedback :
https://extensions.blender.org/add-ons/povable/


You may also be interested in the work of when refactorings tend to occur)

He tried to demonstrate how to implement some object oriented features to POV:
https://news.povray.org/povray.programming/thread/%3Cweb.621b65ab50be6c547283012224d82e4%40news.povray.org%3E/

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Spherical heightfields:
>
> "shapes.inc includes shapes_old.inc and contains many macros for working with
> objects, and for creating special objects, such as bevelled text, spherical
> height fields, and rounded shapes."
> https://wiki.povray.org/content/Reference:Shapes.inc
> So it ought to be in the drop-down insert menu.
>
https://news.povray.org/povray.binaries.images/thread/%3C5f16dc29%40news.povray.org%3E/
>
https://news.povray.org/povray.binaries.images/thread/%3C38a2dc5b%40news.povray.org%3E/

Hmmm ... I will check it, first try looks promising.
But there are some strage "features" in the picture.
Later, in a separate thread.

> Welcome to the club.  It's not big, and you're in it.  ;)
>
> > Or I push my C++ skills and find out if I can work on the development of
> > Povray-Sourcode.
>
> jr and I are looking into that.  But at the moment we're both sort of tied up
> with too much non-POV-Ray real life drudgery.  :(

Yes yes, I know.
Could do it around the clock, but have other things to do, unfortunately.

> > Or I will try the "B-Thing".
> :O  Hush.

:)
I deliberately didn't dare to write the bad word.


ma

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
> > - new functions to handle strings/arrays
>
> can you give some examples of what you (most) miss, please ?

Most of the functions handwritten in my helper package. Searching in strings,
filtering, sorting arrays, etc.
PHP has dozens of functions for this. I wrote most of the ones I needed, but it
was a hell of work. And I'm still amazed that Povray interprets them so quickly,
thought that would slow everything down.

What annoyed me a lot:
You have no chance of figuring out what type a variable is. You have to know
what it is and cant convert them automatically.

On the other hand, povray is not a real programming language but focuses on the
render output.
I am happy about what it can do and that I was able to extend it for myself.
So I don't want to complain.

I have a wish list, but I don't expect anyone to implement it in their free
time. And my programming skills do not allow me to get involved in the project
at the moment. So I have to live with what I have, and that's a lot of fun.

Ma

Post a reply to this message

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "Maetes" <nomail@nomail> wrote:
> >
> > Or I will try the "B-Thing".
>
> Please do ! Our POV-Ray addon needs feedback :
> https://extensions.blender.org/add-ons/povable/

You won't believe it, but coincidentally I tested this just before Christmas!
(or a similar Extension)

My goal was to get some models of NASA spacecraft from Blender to Povray  -
without any B-Thing knowledge!

It worked, more or less, but looks like all Textures were gone.

I canceld further tests, because B was too complicated for me, after > 4 hours I
had enough.

Maybe I will give it another try. Somewhen.

IS THERE A SEPARATE THREAD FOR THIS EXTENSION?

Martin

Post a reply to this message

hi,

"Maetes" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > can you give some examples of what you (most) miss, please ?
> Most of the functions handwritten in my helper package. ...

ok.


> What annoyed me a lot:
> You have no chance of figuring out what type a variable is. You have to know
> what it is and cant convert them automatically.
> On the other hand, povray is not a real programming language but focuses on the
> render output.

so.. :-)  by now (as of 3.7 I think, perhaps earlier) the Scene Description
Language (SDL) is "Turing complete".  but it evolved to that stage, and both
developers and users obsess about "backward compatibility", therefore SDL, the
current parser, is most unlikely to evolve further to offer us worthwhile
"introspection" tools (like WFP started introducing in his branch).


> I am happy about what it can do and that I was able to extend it for myself.
> So I don't want to complain.

is all we do ;-)  (also gets easier with age.  more time to practice :-))


> I have a wish list, but I don't expect anyone to implement it in their free
> time. And my programming skills do not allow me to get involved in the project
> at the moment. So I have to live with what I have, and that's a lot of fun.

+1.


>> jr and I are looking into that.  But at the moment we're both sort of tied up
>> with too much non-POV-Ray real life drudgery.  :(

> Yes yes, I know.
> Could do it around the clock, but have other things to do, unfortunately.

you live in the same world we do, so you do know that it is all about ..
pedalling faster, to keep standing still.  </shrug>  but I think the majority of
"us" would spend more time "povving", if RL allowed.


regards, jr.

Post a reply to this message

On 2025-01-02 13:55 (-4), Maetes wrote:
> 
> Unfortunately, I can't find any item of my personal wish list (except for
> optional parameters) in the revision list of version 3.8.
> These are:
> - spherical heightfields
> - Type-Identification
> - new functions to handle strings/arrays
> - Object-Oriented Programming (Classes)

On my own wish list:
 - An end to scope leakage.  #local scope does not stay local, which
   means that if you write a library, you have to read the minds of
   every other POVer on earth.
 - A call stack postmortem, so you can determine where the parse error
   *really* occurred.

But as jr alluded to, the parser is the biggest monster to be slain in
this software.  It's a recursive descent algorithm and very inflexible.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> But as jr alluded to, the parser is the biggest monster to be slain in
> this software.  It's a recursive descent algorithm and very inflexible.

As this applies to most anything in life:
Hope is not a plan.
No one is coming to save you/us.
Skills are more valuable than things.

As I have brought up in the past, it would probably be a good idea to look
outside of the tiny little corner of the internet that we frequent, and try to
find someone amongst the many academic and commercial computer science people
that use POV-Ray for some purpose, and ask if they can have a student write out
the basic framework of a modern (LR-style?) parser to get things firmly started
in the proper direction.

In the absence of that, what are your thoughts on beginning to write out THE NEW
parser amongst ourselves?  I have seen that someone has already begun doing such
a thing, and perhaps we can all build on whatever contributions people can
offer.

WFP is already writing yuqk.
jr and I have Stroustrup's tome.
Plenty of people are capable of writing some level of code - be it in SDL or
some other language.

Even if we simply start sketching out the framework, others can come in and fill
in the blanks.

I mean, even if the code doesn't actually DO anything and it's just blocks of
comments describing what should be done at each step - we can still write what
amounts to an operational flowchart, where we can just output a summary of what
the code WOULD do if there was functional code in the framework.

- BW

Post a reply to this message

Le 12/01/2025 à 17:37, Bald Eagle a écrit :
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> But as jr alluded to, the parser is the biggest monster to be slain in
>> this software.  It's a recursive descent algorithm and very inflexible.
> 
> As this applies to most anything in life:
> Hope is not a plan.
> No one is coming to save you/us.
> Skills are more valuable than things.
> 
> As I have brought up in the past, it would probably be a good idea to look
> outside of the tiny little corner of the internet that we frequent, and try to
> find someone amongst the many academic and commercial computer science people
> that use POV-Ray for some purpose, and ask if they can have a student write out
> the basic framework of a modern (LR-style?) parser to get things firmly started
> in the proper direction.
> 
> In the absence of that, what are your thoughts on beginning to write out THE NEW
> parser amongst ourselves?  I have seen that someone has already begun doing such
> a thing, and perhaps we can all build on whatever contributions people can
> offer.
> 
> WFP is already writing yuqk.
> jr and I have Stroustrup's tome.
> Plenty of people are capable of writing some level of code - be it in SDL or
> some other language.
> 
> Even if we simply start sketching out the framework, others can come in and fill
> in the blanks.
> 
> I mean, even if the code doesn't actually DO anything and it's just blocks of
> comments describing what should be done at each step - we can still write what
> amounts to an operational flowchart, where we can just output a summary of what
> the code WOULD do if there was functional code in the framework.
> 
> - BW
> 
Hello,
(I apologize in advance for the possible bad english)
I remember some years ago, Christoph Lipka was evocating/evoking the 
Json script language as a replacement of POVRay's Scene description 
language. Maybe the POVRay project should go in this direction.
Regards,
Antoine.

Post a reply to this message

antoine <map### [at] orangefr> wrote:

> Hello,
> (I apologize in advance for the possible bad english)

No worries.  Some of the people who speak the worst English are the ones born in
English-speaking countries.  ;)

> I remember some years ago, Christoph Lipka was evocating/evoking the
> Json script language as a replacement of POVRay's Scene description
> language.

("advocating"?)

https://news.povray.org/povray.pov4.discussion.general/thread/%3C566c3270%40news.povray.org%3E/

I was involved in a very large-scale project, and the way it was organized, was
that those who wanted their "camp" to be considered would submit a "cover
letter" explaining their position, and supported by a "spreadsheet" covering all
of the pros and cons, deficiencies and benefits of their way of going about
things.
People signed up to be part of the team, with the understanding that when a
critical mass was achieved (the development team), they would then do what was
necessary to become an active developer.

In order to "best" determine the will of the active user base / developers, the
Condorcet method was used to select which "camp" would drive the development.
https://en.wikipedia.org/wiki/Minimax_Condorcet_method

I think it would be productive and educational if a list of programming
styles/paradigms was made, with representative specific languages, and then
people with specialized knowledge of each of those languages would fill in the
details, and explain how things are the same, different, beneficial,
detrimental, etc.  Then we could have something to read over and really KNOW
what we want for a "new SDL", and there would historical documentation for the
users to understand WHY - which seems to fill up a lot of recurring newsgroup
threads.

Then we could move on to organizing the complexities of the hierarchies of CSG,
pigments, textures, normals, finishes, uv_mapping, cutaway_textures, etc.

Specifically highlighting good programming practices, and exposing the pitfalls
of certain ways of doing things that lead to ambiguity, unintended results,
scope leakage, etc. (with specific coding examples and results) would minimize
covering the same ground repeatedly, and focus efforts on continual progress,
rather than getting bogged down in rehashing old issues with new contributors.

Once again, I'll point out that a lot of folks here that have been around a long
time, simply don't have the time, energy, focus, round-tuits, programming
experience, writing parsers and lexers, etc to take on something like re-writing
all of SDL from scratch and getting something functioning at the end of it.

So soliciting outside expertise in these areas seems to be less of a suggestion
and more of a critical need.

- BW

Post a reply to this message

hi,

antoine <map### [at] orangefr> wrote:

> > Cousin Ricky <ric### [at] yahoocom> wrote:
> >> But as jr alluded to, the parser is the biggest monster to be slain in
> >> this software.  It's a recursive descent algorithm and very inflexible.
> > As this applies to most anything in life:
> > Hope is not a plan.

that's quotable :-)


> > No one is coming to save you/us.
> > Skills are more valuable than things.
> > As I have brought up in the past, it would probably be a good idea to look
> > outside of the tiny little corner of the internet that we frequent, and try to
> > find someone amongst the many academic and commercial computer science people
> > that use POV-Ray for some purpose, and ask if they can have a student write out
> > the basic framework of a modern (LR-style?) parser to get things firmly started
> > in the proper direction.
> > In the absence of that, what are your thoughts on beginning to write out THE NEW
> > parser amongst ourselves?  I have seen that someone has already begun doing such
> > a thing, and perhaps we can all build on whatever contributions people can
> > offer.
> > WFP is already writing yuqk.
> > jr and I have Stroustrup's tome.
> > Plenty of people are capable of writing some level of code - be it in SDL or
> > some other language.
> > Even if we simply start sketching out the framework, others can come in and fill
> > in the blanks.
> > I mean, even if the code doesn't actually DO anything and it's just blocks of
> > comments describing what should be done at each step - we can still write what
> > amounts to an operational flowchart, where we can just output a summary of what
> > the code WOULD do if there was functional code in the framework.

after some thought, I've decided to start a new thread in
..pov4.discussion.general, subject "SDL2".  over the years there have been a
number of "feature requests", this may be the time to start having them in one
place.

every post to the thread should discuss exactly _one_ new feature / whatever
aspect of SDL programming, with bits of pseudo code to illustrate, as suggested
above.

and yes, a kindhearted academic who'd provide .. support, would be "the ideal".
fingers crossed, it's a big world :-)


> Hello,
> (I apologize in advance for the possible bad english)
> I remember some years ago, Christoph Lipka was evocating/evoking the
> Json script language as a replacement of POVRay's Scene description
> language. Maybe the POVRay project should go in this direction.
> Regards,
> Antoine.

personally, I'd prefer a SDL2 which compiles.  but I would love to have a SDL2
which can read/import objects (say mesh) and or data from .json files.  re "Json
script language", you mean JavaScript ?


regards, jr.

Post a reply to this message