Greetings,

since I'm well known for converting images to something else, POVRay 
scenes included, while thinking on my previous Python-based stuff like 
img2mesh I sort of accumulated different results of my "what if" thoughts.

To capture your attention, attached is the result of rendering of 
converting image heightfield to net structure made of cylinders (with 
sphere joints at joints. Source PNG is the same as used for my img2mesh:
https://dnyarri.github.io/img2mesh.html).

I have some more of them, like constructing pseudo-heightfield from 
blobs, or constructing it from patches (very far from perfect since I'm 
out of ideas of how to interpolate/extrapolate control points), and they 
all are in "let's add this and possibly remove this but who cares about 
user-friendly layout and unused imports" status.

Anyway, back to the main topic: probably someone may find it useful for 
something (turning blurred logos into 3D scenes? Season greetings 
cards?), and surely I'm ready to share all this for free, but I don't 
want having one Github repo for each one, I'd rather prefer to pile them 
together into a single repo.

And that's where a question comes: a good short name for this 
repository. Converting 2D images into POVRay something. What could it be?

"Junk" is the name of my favorite song, so not a choice. Leftovers? 
These programs are not quite left, I may update them (not to mention 
that some people may loathe The Toad's leftovers.

Any ideas?

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Attachments:
Download 'net.png' (332 KB)

Preview of image 'net.png'

Ilya Razmanov <ily### [at] gmailcom> wrote:

> And that's where a question comes: a good short name for this
> repository. Converting 2D images into POVRay something. What could it be?

EsteeL

Sounds like S D L, spelled sorta like Estee Lauder.   :D

- BW

Post a reply to this message

On 16.12.2024 14:39, Bald Eagle wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
> 
>> And that's where a question comes: a good short name for this
>> repository. Converting 2D images into POVRay something. What could it be?
> 
> EsteeL
> 
> Sounds like S D L, spelled sorta like Estee Lauder.   :D

Ahem. Since programs under discussion are Python programs producing SDL, 
I surely may call this project PySDL, but I refuse to explain what it 
sounds like in Russian...

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 16.12.2024 14:39, Bald Eagle wrote:
> > Ilya Razmanov <ily### [at] gmailcom> wrote:
> >> And that's where a question comes: a good short name for this
> >> repository. Converting 2D images into POVRay something. What could it be?
> >
> > EsteeL
> > Sounds like S D L, spelled sorta like Estee Lauder.   :D
>
> Ahem. Since programs under discussion are Python programs producing SDL,
> I surely may call this project PySDL, but I refuse to explain what it
> sounds like in Russian...

or, perhaps, 'PyRay' and pronounce like 'puree' ?  (half serious :-))


regards, jr.

Post a reply to this message

On 16.12.2024 12:37, Ilya Razmanov wrote:
> 
> And that's where a question comes: a good short name for this 
> repository. Converting 2D images into POVRay something. What could it be?

Ok, I see people are just laughing at all this, so I guess I'll call it 
something like "POVSmith". Currently I have more or less functional 
variants for export from PNG and PNM to POVRay pseudo-heightfield 
patches, or blobs, or net structure I sent here. They still need more 
work (just found a bug in patches), but still I think I'll be able to 
turn it into something I can show people without feeling a shame.

Still, I have more questions.

Right now I changed stuff so it exports two files - .pov with some scene 
stub and .inc with main object, so it's easier to edit the scene and 
will simplify plugging object into another scene. What is people opinion 
- is it a good idea?

Following question is, for importing PNM I wrote small yet fully 
operational module (and even dared to upload it to PyPI as "PyPNM") 
which reads PPM and PGM files and returns image as nested list (and, 
surely, may do the opposite), so it becomes easier to assemble image 
editors and stuff from blocks, exchanging data as nested lists of 
logical structure. The question is, I may do the same with POVRay 
pseudo-heightfield export (including my img2mesh), thus making it easier 
for other potential developers to assemble something funny from a ready 
blocks (I always said that we need something like POVRay virtual printer 
driver so one may send any document to it and get a 3D rendering of it, 
lol). The question is - is anybody interested?

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:


> Right now I changed stuff so it exports two files - .pov with some scene
> stub and .inc with main object, so it's easier to edit the scene and
> will simplify plugging object into another scene. What is people opinion
> - is it a good idea?

Probably a good idea - however one option that you want to explore is just
making a single file that detects whether it's the main scene or an included
file.

(can't recall the specifics of how to do this off the top of my head)

Basically you'd do an if (main scene) then enable all stuff needed to render a
full scene #else just declare the object.

Then you get both options for the (disk space) price of one.

- BW

Post a reply to this message

On 23.12.2024 20:42, Bald Eagle wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
> 
> Probably a good idea - however one option that you want to explore is just
> making a single file that detects whether it's the main scene or an included
> file.

I was thinking about this once (would be good for self-illustrating 
includes. For example, for my "POVRay mosaic" I may use rather complex 
objects in presets as includes, so I tried out making include 
self-rendering, but failed), but main problem is that with POVRay I 
can't do "from filename import nameofwhatiwant", I can only "import 
filename" with camera and stuff, and, when I tested it long ago, local 
camera was replacing global (at best).

So now I tried to split file in part like "thething geometry as .inc" 
and "camera light then import thething then texture and transform as .pov".

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:

Found it.
https://news.povray.org/povray.general/message/%3CXnsAC0E5196CA622seed7%40news.povray.org%3E/#%3CXnsAC0E5196CA622seed7%
40news.povray.org%3E

So what you do is this:

#if (input_file_name = "MySceneFile.inc")

   Camera
   Lights
   whatever else

#end

Then rest of your scene is _just_ the include file.

That way, if you're including your file in another file, it doesn't run the
extra scene setup code.
But if you're running it as a standalone file, you obviously need the scene
setup stuff to render anything - and so it's all right there.

- BW

Post a reply to this message

On 24.12.2024 18:03, Bald Eagle wrote:

> So what you do is this:
> 
> #if (input_file_name = "MySceneFile.inc")
> 
>     Camera
>     Lights
>     whatever else
> 
> #end
>

Hm, I've seen "Input_File_Name" in "Command-Line and INI-File Options", 
and I always assumed that all this work only with ini and stuff.

So, it works within scene as well? Where can I learn more about this 
(beside thin NG, I mean. Surely I ask questions here sometimes, but 
still I understand that teaching me POVRay is not the main reason for 
this NG existence)? There are ways to control stuff from the scene that 
are normally controlled from ini?

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:

> Hm, I've seen "Input_File_Name" in "Command-Line and INI-File Options",
> and I always assumed that all this work only with ini and stuff.

It does not control anything.  It's a defined identifier.

> So, it works within scene as well? Where can I learn more about this
> (beside thin NG, I mean.

Always the WIKI:
https://wiki.povray.org/content/Reference:Strings

It also looks like
the link for input_file_name at
https://wiki.povray.org/content/Reference:Keywords
is supposed to have a reference to this keyword - but doesn't.

> Surely I ask questions here sometimes, but
> still I understand that teaching me POVRay is not the main reason for
> this NG existence)?

No way.  Our time machine was invented just to go back and make it all for you!
:)
We all are learners being taught, and become teachers of our own little areas of
experience and expertise.

> There are ways to control stuff from the scene that
> are normally controlled from ini?

.. . . sort of.
If you look at the way the sample scenes get automagically generated from a
script, the script is actually doing the controlling, but it uses the image
sizes that it reads from within the scene file.

Also, if you look up my self-including include file, then you might invent a way
 to parse values in the scene, (over)write to the file, and then include it
again....

You might be able to (re)write the resolution.ini file, or something - but I
think POV-Ray generally doesn't allow for potentially malicious coding exploits.

- BW

Post a reply to this message

Well, as major Kaprov said, "if I did something wrong please report and 
then I will be thinking". I guess I will follow this old army procedure 
and be thinking :-)

> You might be able to (re)write the resolution.ini file, or something - but I
> think POV-Ray generally doesn't allow for potentially malicious coding exploits.

Don't worry, I'm famous for my capabilities to send PC into an infinite 
loop, filling all the memory. That's what recursions (see "Recursions") 
are invented for.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 24.12.2024 20:32, Bald Eagle wrote:

> We all are learners being taught, and become teachers of our own little areas of
> experience and expertise.

Ok, I just discovered #ifndef which makes it easy to have defaults in 
.inc yet override them with .pov stub.

Dementia is great decease - no pain, and you learn something new every 
day! (c) local saying

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 24.12.2024 18:03, Bald Eagle wrote:

> So what you do is this:
> 
> #if (input_file_name = "MySceneFile.inc")
> 
>     Camera
>     Lights
>     whatever else
> 
> #end
> 
> Then rest of your scene is _just_ the include file.

Well, don't quite like this solution since it's not immune to simple 
file rename. But I started to think (yes, following comrade major 
scheme) and eventually and inevitably came to conclusion that

#declare extension = substr(input_file_name, strlen(input_file_name) - 3, 4)

#debug extension

shows me

.pov

and even subsequent

#if (extension = ".pov")
   #debug "Match!\n"
#end

says "Match!"

Combining it with your suggestion, I guess I can produce files that work 
as a whole scene when they are .pov, and as include after renaming to .inc

But this is not confirmed experimentally yet ;-)

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:

> Well, don't quite like this solution since it's not immune to simple
> file rename.

It ought to be.

Write a tiny .pov file that outputs the value of input_file_name to the debug
stream.   Rename the file.  Render it again.

Since you're opening the file as the main .pov file, that's what input_file_name
gets defined as.

If you write another .pov file that INCLUDES the first .pov file, then it's the
main file that gets its filename assigned to input_file_name.

That's why this ought to be a good solution for you.

Just try it - you'll see.

- BW

Post a reply to this message

On 03.01.2025 18:53, Bald Eagle wrote:
> 
> If you write another .pov file that INCLUDES the first .pov file, then it's the
> main file that gets its filename assigned to input_file_name.

Yep, already tried my idea with extensions out - oops, it seems like 
.inc file gets extension from master file, which is .pov, so my idea 
with extensions doesn't work. Guess it was just too beautiful for this 
world...

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 03.01.2025 18:53, Bald Eagle wrote:
> 
> That's why this ought to be a good solution for you.
> 

...on the other hand, I still may use extension trick to make 
self-rendering .inc as you suggested, but reacting to extension only 
rather that a whole file name...

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>
> Found it.
>
https://news.povray.org/povray.general/message/%3CXnsAC0E5196CA622seed7%40news.povray.org%3E/#%3CXnsAC0E5196CA622seed
7%
> 40news.povray.org%3E
>
> So what you do is this:
>
> #if (input_file_name = "MySceneFile.inc")
>
>    Camera
>    Lights
>    whatever else
>
> #end
>
> Then rest of your scene is _just_ the include file.
>
> That way, if you're including your file in another file, it doesn't run the
> extra scene setup code.
> But if you're running it as a standalone file, you obviously need the scene
> setup stuff to render anything - and so it's all right there.
>
> - BW

That works alright. But, I've use this for a long time

#ifndef(Get)
 do what ever
#end

Then define 'Get' in the calling file. This works even if you change the name of
 the inc file. Which I do often when I'm testing ideas.
I really should use the 'input_file_name' test more.
Have fun!

Post a reply to this message

On 03.01.2025 22:42, Leroy wrote:

> That works alright. But, I've use this for a long time
> 
> #ifndef(Get)
>   do what ever
> #end

LOL. That's too simple to think of it ;-)))


-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Le 2025-01-03 à 16:19, Ilya Razmanov a écrit :
> On 03.01.2025 22:42, Leroy wrote:
> 
>> That works alright. But, I've use this for a long time
>>
>> #ifndef(Get)
>>   do what ever
>> #end
> 
> LOL. That's too simple to think of it ;-)))
> 
> 

The includes from the distribution use a trick like that.

#ifndef(Flag)
#declare Flag=version;
  do include stuff
#end

This prevent parsing the include multiple times if it get formally 
included and included by another include.

Post a reply to this message