povray.binaries.utilities message digest

[yesbird] Re: POV-Ray studio [173 days 4 hours and 2 minutes ago]

Wed, 22 Oct 2025 01:38:59 GMT

https://povlab.yesbird.online/studio/
-- 
YB

[yesbird] Re: POV-Ray studio [173 days 4 hours and 7 minutes ago]

Wed, 22 Oct 2025 01:33:51 GMT

Update is available (0.19 "Metal"):

1. Materials updated, metal finish adjusted according Alain suggestion.

2. Demo models updated.
-- 
YB

[yesbird] Re: POV-Ray studio [177 days and 17 minutes ago]

Sat, 18 Oct 2025 05:24:39 GMT

New experimental feature - model animation:
https://povlab.yesbird.online/studio/?m=gears.glb
--
YB

[yesbird] Re: POV-Ray studio [179 days 6 hours and 5 minutes ago]

Wed, 15 Oct 2025 23:36:48 GMT

As the project is completed, I shared the code under the MIT license for
those, who want to extend or improve it:
https://github.com/syanenko/pov_studio
--
YB

[yesbird] Re: POV-Ray studio [179 days 7 hours and 50 minutes ago]

Wed, 15 Oct 2025 21:51:16 GMT

After final cleanup and writing a short README I guess
this projects is completed and I am switching to something completely
different - animations of paintings in VR. Please notify me about
issues, if any.

Happy rendering !
--
YB

[yesbird] Re: POV-Ray studio [180 days 13 hours and 12 minutes ago]

Tue, 14 Oct 2025 16:28:53 GMT

Update: 0.16b "UV"

1. Export Textures and UVs as arrays.

2. Unions excluded from export: now exporting only objects
    with materials.
--
YB

[yesbird] Re: Online files converter [181 days 3 hours and 44 minutes ago]

Tue, 14 Oct 2025 01:57:11 GMT

On 14/10/2025 03:45, yesbird wrote:
> I mentioned somewhere, that these materials are from Mike Miller's
> collection. To browse them please enter materials directory and render
> 'samples_default.pov' (http://localhost:8085/data/download/studio.zip).

Sorry, it's time to sleep :):
https://povlab.yesbird.online/studio/data/download/studio.zip
--
YB

[yesbird] Re: Online files converter [181 days 4 hours and 56 minutes ago]

Tue, 14 Oct 2025 00:45:14 GMT

On 14/10/2025 03:26, Kenneth wrote:
> For your 'materials', are you using your own creations? I would suggest using
> the standard textures that come with POV-ray instead, available in its 'include'
> folder (perhaps in 'textures.inc', 'glass.inc', etc.)  For example, your
> 'M_yellow_green_gloss' material is not included in POV-ray as far as I can tell,
> and could be confusing to a user when first trying to render the mesh2. (It also
> causes an error.)

I guess it's time to write a help system :). Short notes about how to
use the studio and materials available by clicking (?).

I mentioned somewhere, that these materials are from Mike Miller's
collection. To browse them please enter materials directory and render
'samples_default.pov' (http://localhost:8085/data/download/studio.zip).

You are absolutely right about standard materials, I will include them
in my library later, after finishing main functionality. In general,
preparing materials is a simple, but time consuming task, moreover I
need to adjust lighting for better matcap rendering. Any assistance
related to this part of the project is highly appreciated. :)
-- 
YB

[Kenneth] Re: Online files converter [181 days 5 hours and 11 minutes ago]

Tue, 14 Oct 2025 00:30:00 GMT

yesbird wrote:
> On 13/10/2025 19:58, Kenneth wrote:
> > YES, that worked; and thanks for that cube object, ...
>
> I've just
> reversed vertices order, and it works fine now (check it, please).

YES, both the smooth and flat versions render correctly now; the outsides and
insides are where they should be! Excellent.
>
>
> I am using unions to reflect the structure of the original scene for
> technical purposes. Using objects is necessary for materials assignment
> to different parts (meshes) of complex models.

Ah yes, I understand now. For my own purposes, I will just delete the unions.

---------

For your 'materials', are you using your own creations? I would suggest using
the standard textures that come with POV-ray instead, available in its 'include'
folder (perhaps in 'textures.inc', 'glass.inc', etc.)  For example, your
'M_yellow_green_gloss' material is not included in POV-ray as far as I can tell,
and could be confusing to a user when first trying to render the mesh2. (It also
causes an error.)

[yesbird] Re: Online files converter [181 days 11 hours and 13 minutes ago]

Mon, 13 Oct 2025 18:28:09 GMT

On 13/10/2025 19:58, Kenneth wrote:
> YES, that worked; and thanks for that cube object, ...

Always welcome, now this testing cube is available at [1] button.

> Anyway, at least *part* of the mystery has been cleared up :-D

The answer is simple: order of vertices define normal direction.
When normals specified, they overwrite this calculation. I've just
reversed vertices order, and it works fine now (check it, please).

> In my opinion, the 'union' at the end of the converted file(s) is not really
> necessary, nor is the 'part1' object there. The converted .inc file by itself
> would be easier to render in one of our scenes, just by #including it there.

I am using unions to reflect the structure of the original scene for
technical purposes. Using objects is necessary for materials assignment
to different parts (meshes) of complex models. But if you see an
alternative and better solution, please share your thoughts.
--
YB

[yesbird] Re: Online files converter [181 days 11 hours and 23 minutes ago]

Mon, 13 Oct 2025 18:18:03 GMT

On 13/10/2025 20:24, Bald Eagle wrote:
> I'm going to just speculate that since mesh2 and smooth_triangle both allow the
> user to specify what the normal vector is, then perhaps that overrides whatever
> normal would be calculated based upon the ordering of the vertices.

You are absolutely right. I've just reversed vertices order, and it
works fine now.
-- 
YB

[Bald Eagle] Re: Online files converter [181 days 12 hours and 16 minutes ago]

Mon, 13 Oct 2025 17:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> When I convert it to SMOOTH triangles (the default at your conversion site), the
> cube appears CORRECT as to inside/outside colors. That surprised me.
>
> When I convert it to FLAT triangles, the inside/outside is *reversed*.

I'm going to just speculate that since mesh2 and smooth_triangle both allow the
user to specify what the normal vector is, then perhaps that overrides whatever
normal would be calculated based upon the ordering of the vertices.

- BW

[Kenneth] Re: Online files converter [181 days 12 hours and 36 minutes ago]

Mon, 13 Oct 2025 17:05:00 GMT

yesbird wrote:
> On 13/10/2025 14:03, Kenneth wrote:
> > I just tried uploading 'cube.fbx' to your converter, but it does not load there.
> > ...
>
> Thanks for testing, could you please take file from here
> and try again ?
>

YES, that worked; and thanks for that cube object, because I was able to
discover what is causing the inside-out-triangles problem...and the confusion
for both you and me! I made two conversion tests (deleting your 'material' and
substituting a texture plus an interior texture.)

When I convert it to SMOOTH triangles (the default at your conversion site), the
cube appears CORRECT as to inside/outside colors. That surprised me.

When I convert it to FLAT triangles, the inside/outside is *reversed*. (This is
how I have been converting objects there, and I did not know until now that the
two schemes produced different results.)

I have attached a POV-ray scene file to show both of the examples side by side.
The green cube is the smooth-triangle version; the red one is flat triangles.

From examining both of the mesh2 code examples, it is not clear to me why the
two results should be different-- although I am not very knowledgeable about
mesh2 syntax.

Anyway, at least *part* of the mystery has been cleared up :-D

-----------
In my opinion, the 'union' at the end of the converted file(s) is not really
necessary, nor is the 'part1' object there. The converted .inc file by itself
would be easier to render in one of our scenes, just by #including it there.

[yesbird] Re: POV-Ray studio [181 days 12 hours and 40 minutes ago]

Mon, 13 Oct 2025 17:01:34 GMT

Update is available (0.15b "XR"):

1. XR mode support (click box icon at the top right).
    If you don't have VR headset, you can use emulator:
https://chromewebstore.google.com/detail/immersive-web-emulator/cgffilbpcibhmcfbgggfhfolhkfbhmik?hl=en

2. Minor export fixes.
--
YB

[yesbird] Re: Online files converter [181 days 18 hours and 9 minutes ago]

Mon, 13 Oct 2025 11:32:31 GMT

On 13/10/2025 14:03, Kenneth wrote:
> I just tried uploading 'cube.fbx' to your converter, but it does not load there.
> ...

Thanks for testing, could you please take file from here
and try again ?

https://drive.google.com/file/d/19i3tetZYJzlKQcOPR_rUEI1n-m2LCwtS/view?usp=drive_link

> 
> I have attached one of my recent STL-to-mesh2 conversions from your site
> ...

Sorry, but without complete scene with textures I can't reproduce it -
still confused. But now you can export model with arrays and make
desired perturbations as Bill suggested - just select 'Export arrays'
at low-left corner.
-- 
YB

[Kenneth] Re: Online files converter [181 days 18 hours and 36 minutes ago]

Mon, 13 Oct 2025 11:05:00 GMT

yesbird wrote:
> On 10/10/2025 13:22, Kenneth wrote:
> > It seems that the resulting mesh2 triangles are facing 'inside out'...
> > ...
>
> Thanks you for this bug report, I have just tried to reproduce this
> behavior and didn't found any difference between images with forward and
> backward faces order. Could you please send me a simple example,
> illustrating this issue ? For simplicity, please find a 'cube.fbx'
> in attachment - you can use it with my converter.
> --

I just tried uploading 'cube.fbx' to your converter, but it does not load there.
This *might* be because it showed up as 'cube.fbx.dat' for me when I initially
downloaded it here. (This is typical behavior of the Pov-ray newsgroup website
that I use, regarding downloads; a .dat container is appended to all files.
Unfortunately, I cannot strip that addition from the file, for re-uploading to
your converter.) But I don't know if this is the actual cause of the problem; it
is just my guess.

I have attached one of my recent STL-to-mesh2 conversions from your site
as an .inc file-- a model originally from Thingiverse-- to illustrate the
inside-out triangle result. When rendered in POV-ray, it needs both a texture
and an interior_texture, so that the latter will show the problem. (When using
just a typical texture alone, the triangles' insides and outsides look the
SAME...which gives a false impression of the situation.)

[yesbird] Re: Online files converter [182 days 8 hours and 22 minutes ago]

Sun, 12 Oct 2025 21:19:27 GMT

On 10/10/2025 13:22, Kenneth wrote:
> It seems that the resulting mesh2 triangles are facing 'inside out'-- the
> insides face outside and vice versa. See my attached render of an STL (binary)
> file that I uploaded to your page and converted tonight.
> ...

Thanks you for this bug report, I have just tried to reproduce this
behavior and didn't found any difference between images with forward and
backward faces order. Could you please send me a simple example,
illustrating this issue ? For simplicity, please find a 'cube.fbx'
in attachment - you can use it with my converter.
--
YB

[yesbird] Re: POV-Ray studio [182 days 9 hours and 4 minutes ago]

Sun, 12 Oct 2025 20:37:39 GMT

Update is available (0.14b "Arrays"):

1. Exporting vertex and normals data as arrays
    (check 'Export arrays' at low-left corner).

2. Six demo models included (at top-right corner).
--
YB

[yesbird] Re: Online files converter [182 days 9 hours and 15 minutes ago]

Sun, 12 Oct 2025 20:26:23 GMT

On 10/10/2025 14:02, Bald Eagle wrote:
> If you put your triangle vertices into an array and referenced them by index,
> then it's something that can be adjusted - and even used as data apart from the
> mesh2 definition.  Hard-coding the structure makes it inaccessible from SDL,
> which has been a long-standing complaint in POV-Ray development.

It's done: just select 'Export arrays' checkbox at low-left corner:
https://povlab.yesbird.online/studio/

Hope it will be useful.
--
YB

[yesbird] Re: POV-Ray studio [183 days 8 hours and 40 minutes ago]

Sat, 11 Oct 2025 21:01:16 GMT

New release is ready:

-- In this release (0.12b "Mars") --

1. Fixed issue with loading 'Ingenuity_Mars_Helicopter.glb' (Maetes) -
    now scene hierarchy is preserved.

2. Source file name now included in 'model.ini' header to distinguish
    them (Maetes).

-- In next release --

1. Storing triangle vertices in array (Bill).

2. Improving rendering quality ('scene.pov' tweaking).

3. Extending materials library.
--
YB

[yesbird] Re: Online files converter [184 days 11 hours and 39 minutes ago]

Fri, 10 Oct 2025 18:02:04 GMT

On 09/10/2025 13:54, Mr wrote:
> I sent you an email.

Replied to you yesterday.
Everything is ready for integration with Blender.
--
YB

[yesbird] Re: Online files converter [184 days 13 hours and 26 minutes ago]

Fri, 10 Oct 2025 16:15:44 GMT

On 10/10/2025 14:02, Bald Eagle wrote:
> Yes, our left-handed coordinate system can drive people crazy at times.
> It's also why things are best coded to be adjustable.
> ...

Thanks, Bill, using arrays is a very good idea, I will think about
details of implementation to make this feature useful and flexible,
then include in next release.

I can also imagine a set of switchable options to control desired
format, including orientation of coordinate system - any proposals are
are welcome.

Besides controlling the mesh itself, arrays will allow decoration by
additional elements, positioned at the vertices, achieving different
interesting effects, like on attached image.
--
YB

[Kenneth] Re: Online files converter [184 days 17 hours and 41 minutes ago]

Fri, 10 Oct 2025 12:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Yes, our left-handed coordinate system can drive people crazy at times.
>

Yeah, *that* topic probably needs a fresh-discussion thread of its own, just as
a 'refresher course.'

But as it impacts STL conversion: All of the STL files I've worked with recently
follow the 'right-hand rule'-- the +x direction faces LEFT rather than to the
right as in POV-ray. (Another 3D-printing standard, apparently.) So STL-to-mesh
conversions have to be mirror-flipped in x to render correctly for us. In my own
code, I simply scaled the final mesh by <-1,1,1>.

[Bald Eagle] Re: Online files converter [184 days 18 hours and 36 minutes ago]

Fri, 10 Oct 2025 11:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> However, this is NOT a fault of your conversion process: I noticed the same
> behavior while working on my own POV-ray STL-to-mesh converter. The 3 vertices
> in each STL triangle are apparently written the opposite way 'around the clock'
> -- opposite chirality-- according to how *POV-ray* expects them. I had to fix
> this in my own code, simply by swapping the triangles' 3rd point for the 1st.
> Like:
>
> an original STL triangle:
> triangle{<1,2,3>, <4,5,6>, <7,8,9>}
>
> for correct POV-ray rendering:
> triangle{<7,8,9>, <4,5,6>, <1,2,3>}
>
> STL files (and 3D printers) are apparently standardized for a 3-vertex chirality
> that is opposite to POV-ray's own triangle-rendering scheme.

Yes, our left-handed coordinate system can drive people crazy at times.
It's also why things are best coded to be adjustable.

If you put your triangle vertices into an array and referenced them by index,
then it's something that can be adjusted - and even used as data apart from the
mesh2 definition.  Hard-coding the structure makes it inaccessible from SDL,
which has been a long-standing complaint in POV-Ray development.

Loading the data into an array makes it available to the user to post-process
after loading.

<-1, 0, 1> *  1 + 1 = array indices <0, 1, 2>
<-1, 0, 1> * -1 + 1 = array indices <2, 1, 0>
So everything is easily flipped with a simple pre-multiplier

It also allows mesh deformation (similar to what Josh English wanted to do)
because you have direct access to modify the data.
It also allows you to compute the normals differently.

Not saying that Sergei has to do it that way, but it definitely is something to
think about, and perhaps experiment with implementing in your own converter.

- BW

[yesbird] Re: Online files converter [184 days 18 hours and 46 minutes ago]

Fri, 10 Oct 2025 10:55:06 GMT

On 10/10/2025 13:22, Kenneth wrote:
> I *just* noticed something odd about your online STL-to-mesh2 conversion
> process. (I should have mentioned it before now, but was too busy working on my
> own converter; my apologies.)
> ...

It's interesting, thank you for detailed feedback, I will check it and
post the results here. Testing is highly appreciated at this state of
the project.
-- 
YB

[Kenneth] Re: Online files converter [184 days 19 hours and 16 minutes ago]

Fri, 10 Oct 2025 10:25:00 GMT

yesbird wrote:
> On 08/10/2025 18:29, kurtz le pirate wrote:
> > Have you noticed any improvements ?
>
> Yes, I am working hard and updating it daily, fixing the bugs and
> implementing new features.

I *just* noticed something odd about your online STL-to-mesh2 conversion
process. (I should have mentioned it before now, but was too busy working on my
own converter; my apologies.)

It seems that the resulting mesh2 triangles are facing 'inside out'-- the
insides face outside and vice versa. See my attached render of an STL (binary)
file that I uploaded to your page and converted tonight.

In the converted mesh2 file, I first deleted your union{...} and material{...}
at the end, then rendered the mesh2 with my own textures: A regular texture AND
an interior_texture.

However, this is NOT a fault of your conversion process: I noticed the same
behavior while working on my own POV-ray STL-to-mesh converter. The 3 vertices
in each STL triangle are apparently written the opposite way 'around the clock'
-- opposite chirality-- according to how *POV-ray* expects them. I had to fix
this in my own code, simply by swapping the triangles' 3rd point for the 1st.
Like:

an original STL triangle:
triangle{<1,2,3>, <4,5,6>, <7,8,9>}

for correct POV-ray rendering:
triangle{<7,8,9>, <4,5,6>, <1,2,3>}

STL files (and 3D printers) are apparently standardized for a 3-vertex chirality
that is opposite to POV-ray's own triangle-rendering scheme.

[yesbird] Re: POV-Ray studio [185 days 6 hours and 15 minutes ago]

Thu, 9 Oct 2025 23:26:06 GMT

New release is ready:

-- In this release (0.11b "Pingouin") --

1. Saving model in GLB/GLTF format with materials tags to preserve
    materials tags for future edit.

2. Displaying model's statistics.

--  Known issues --

1. On import GLB/GLTF groups are not supported yes, so some issues
    are possible (ex. 'Ingenuity Mars Helicopter.glb' from Mr).
-- 
YB

[Mr] Re: Online files converter [185 days 18 hours and 46 minutes ago]

Thu, 9 Oct 2025 10:55:00 GMT

yesbird wrote:
> On 09/10/2025 10:06, Mr wrote:
> > Your materials are even improving, and already looked very good !
>
> Thanks for kind words, but still there is a space for improvement.
> I hope more experienced POV-Ray community will help me to do that.
>
> > Please I insist, that it's a bad strategy to despise phones because as far as I
> > know, POV is still as of today the only 3D renderer working on Android through
> > its Termux port. (and no it does not overheat!)
> > and instead of Tik Tok the youths could have something so much better to do with
> > them ;-)
>
> It's a very unexpected, but interesting idea, I will consider it in
> future, although supporting phones is painful because of too many
> different resolutions. Right now I would like to concentrate on main
> functionality and extending the materials library.
>
> Btw, I am almost ready to make a proposal about integration to Blender's
> developer, you, mentioned earlier, and will write it today.  Hope for
> productive collaboration.
>
> PS: Zoomers preferes games, vintage SDL is not for them ).
> --
> YB

I sent you an email.

[yesbird] Re: Online files converter [185 days 20 hours and 48 minutes ago]

Thu, 9 Oct 2025 08:52:54 GMT

On 09/10/2025 10:06, Mr wrote:
> Your materials are even improving, and already looked very good !

Thanks for kind words, but still there is a space for improvement.
I hope more experienced POV-Ray community will help me to do that.

> Please I insist, that it's a bad strategy to despise phones because as far as I
> know, POV is still as of today the only 3D renderer working on Android through
> its Termux port. (and no it does not overheat!)
> and instead of Tik Tok the youths could have something so much better to do with
> them ;-)

It's a very unexpected, but interesting idea, I will consider it in
future, although supporting phones is painful because of too many
different resolutions. Right now I would like to concentrate on main
functionality and extending the materials library.

Btw, I am almost ready to make a proposal about integration to Blender's
developer, you, mentioned earlier, and will write it today.  Hope for
productive collaboration.

PS: Zoomers preferes games, vintage SDL is not for them ).
--
YB

[kurtz le pirate] Re: Online files converter [185 days 22 hours and 5 minutes ago]

Thu, 9 Oct 2025 07:36:08 GMT

On 08/10/2025 23:41, yesbird wrote:
> On 09/10/2025 00:03, Kenneth wrote:
>> Does your analysis of Kurtz's file indicate duplicate *triangles*, or 
>> just
>> duplicate vertices? Kurtz is converting his STL file to plain mesh 
>> AFAIU (not
>> mesh2)-- and in such files there are necessarily many duplicate 
>> vertices, since
>> they are shared among some triangles. I'm guessing that your own mesh2
>> conversion code 'consolidates' those somehow-- resulting in fewer 
>> vertices
>> overall.
>>
>> My apologies; I was confusing your OBJ file discussion with STL file 
>> conversion.
> 
> I only answered the Kurtz's question about difference in of vertices in
> our results. There is no *.inc file in Kurtz's zip, so I grepped obj.


Sorry, I forgot the INC file.
Here now ;)



>> If so, is this consolidation or merging one of the 'efficiency' 
>> benefits of
>> POV-ray's own mesh2 construct, or is it an extra operation that you 
>> added to
>> your own conversion code?
> 
> My conversion process is following:
> 1. Calling OBJLoader() from Three.js library to load meshes into scene.
> 
> 2. Call standard Three.js mergeVertices() method for each mesh on load
> to build vertices index, that completely excludes duplicates.
> 
> 3. Call my POVExporter(), which traverses scene, selects meshes and
> saves data to model.ini as mesh2.
> 
> Very simple :)


-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Online files converter [185 days 22 hours and 9 minutes ago]

Thu, 9 Oct 2025 07:32:46 GMT

On 08/10/2025 23:22, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> Does your analysis of Kurtz's file indicate duplicate *triangles*, or just
>> duplicate vertices? Kurtz is converting his STL file to plain mesh AFAIU (not
>> mesh2)--
> 
> My apologies; I was confusing your OBJ file discussion with STL file conversion.
> 
> 

Indeed, but that's okay.
And yes, I also have an obj2pov, stl2pov, eps2pov,  scripts.



-- 
kurtz le pirate
compagnie de la banquise

[Mr] Re: Online files converter [185 days 22 hours and 31 minutes ago]

Thu, 9 Oct 2025 07:10:00 GMT

Your materials are even improving, and already looked very good !

Please I insist, that it's a bad strategy to despise phones because as far as I
know, POV is still as of today the only 3D renderer working on Android through
its Termux port. (and no it does not overheat!)
and instead of Tik Tok the youths could have something so much better to do with
them ;-)

[yesbird] Re: Online files converter [186 days 2 hours and 29 minutes ago]

Thu, 9 Oct 2025 03:12:38 GMT

On 09/10/2025 05:17, Bald Eagle wrote:
> yesbird wrote:
> 
> I guess various packages have "tolerance" and "decimation error" settings...
...
> How to calculate it?
> Rounding and truncation, I would imagine.

Thank you for parsing Google search results, but I do not see a
concrete formula for precision calculation :).

Long things short: Paul Bourke after reviewing the first version of
converter was wondering why the precision of the data was changed
(increased) on conversion and suggested leaving it as it was in the
input file. I guess this makes sense, because we don't recalculate
coordinates, but simply repack them from one format to another.

In the next release I will follow his advice.
--
YB

[Bald Eagle] Re: Online files converter [186 days 3 hours and 21 minutes ago]

Thu, 9 Oct 2025 02:20:00 GMT

yesbird wrote:

> Not sure that this is the most important thing to do now,
> but could you give an examples of the modern systems with adjustable
> precision and method they use to calculate it ?

(I wasn't making a value judgement about its importance or timeliness, I was
just making an observation.)

I guess various packages have "tolerance" and "decimation error" settings.

https://help.autodesk.com/view/PWRS/2025/ENU/?guid=GUID-465F277C-E3AE-4D83-B14E-0832137FCF4D

https://www.open3d.org/docs/latest/python_api/open3d.t.geometry.TriangleMesh.html

Simplify mesh by Threshold: This is an easy way to reduce the file size of a
mesh for manufacturing. This block will create the mesh with the least amount of
faces. A good starting point for the threshold is 1/4 to 1/8 of the
manufacturing tolerance.
Simplify mesh by Amount: This block generates a mesh that is smaller than the
original based on the specified amount. For example, a value of 0.9 will create
a mesh with 90% fewer faces, and as a result 90% smaller file size.
https://www.ntop.com/resources/blog/meshing-in-fea-cfd-manufacturing/

https://help.altair.com/inspire/en_us/topics/implicit/visualization_r.htm#:~:text=This%20is%20usually%20seen%20in,doing
%20this%20is%20shown%20below.

https://support.carveco.com/hc/en-gb/articles/19604059276316-3D-Design-Creating-Triangle-Mesh-For-Exporting#:~:text=The
%20two%20settings%20work%20hand,tolerance%20low%20and%20optimisation%20enabled.

https://nexus.hexagon.com/documentationcenter/en-US/bundle/VISI_2025_2_FLOW_Online_Help/page/Content/CadMeshTolerance.h
tml

Lots of search results for "triangle mesh decimation"

This would probably be the biggest file-size optimizer, because there's no
reason to have a cube with 10,000 coplanar triangle faces when 2 would
indistinguishably do the job - probably with more accuracy and fewer artifacts
to due to floating point noise.

How to calculate it?
Rounding and truncation, I would imagine.

> I see that C4D gives 14 digits (attached).

[yesbird] Re: Online files converter [186 days 3 hours and 53 minutes ago]

Thu, 9 Oct 2025 01:48:24 GMT

On 09/10/2025 04:23, Bald Eagle wrote:
> Hard-coding magic numbers doesn't seem like the way to go if it isn't to
> difficult to make everything adjustable.

Not sure that this is the most important thing to do now,
but could you give an examples of the modern systems with adjustable
precision and method they use to calculate it ?

I see that C4D gives 14 digits (attached).
-- 
YB

[Bald Eagle] Re: Online files converter [186 days 4 hours and 16 minutes ago]

Thu, 9 Oct 2025 01:25:00 GMT

yesbird wrote:
> Necessary precision is really dependent on a
> model's scale. Current release has 6 digits, let's try to test it. I
> guess, the file size is not a serious limitation, so increasing to 8-10
> is possible.

Just a cautionary observation.

It's difficult or impossible to predict the end user's use of a model or the
precision they need.

Is it possible to have the user select the desired precision before conversion?
Can a file size be estimated based on the number of vertices and the selected
precision?

Hard-coding magic numbers doesn't seem like the way to go if it isn't to
difficult to make everything adjustable.

- BW

[yesbird] Re: Online files converter [186 days 4 hours and 45 minutes ago]

Thu, 9 Oct 2025 00:56:14 GMT

On 09/10/2025 03:21, Kenneth wrote:
> In my own POV-ray-only stl-to-mesh converter-- not yet posted ;-) -- I came to
> the same conclusion: that 4 or 5 digits were enough, and that more were simply
> overkill. In my experience, some models' float values are written with much more
> precision than is necessary...

Many thanks for sharing the results of your investigation - there is a
space for analysis here. Necessary precision is really dependent on a
model's scale. Current release has 6 digits, let's try to test it. I
guess, the file size is not a serious limitation, so increasing to 8-10
is possible.
--
YB

[yesbird] Re: POV-Ray studio [186 days 4 hours and 58 minutes ago]

Thu, 9 Oct 2025 00:43:36 GMT

On 09/10/2025 03:39, yesbird wrote:
> Little by little and simple format converter is turning into an online
> workshop for exploring and painting models, so, I guess, it's time for
> rebranding :).

New address: https://povlab.yesbird.online/studio/
-- 
YB

[yesbird] POV-Ray studio [186 days 5 hours and 2 minutes ago]

Thu, 9 Oct 2025 00:39:45 GMT

Little by little and simple format converter is turning into an online
workshop for exploring and painting models, so, I guess, it's time for
rebranding :).

-- In this release (0.10b "Pingouin") --

1. Start of the materials library: 12 items from Mikes Miller's
collection (look at 'materials' directory of scene template:
https://povlab.yesbird.online/studio/data/download/studio.zip and render
samples_default.pov to browse whole  collection).

2. Processing materials tags from the "extras" section of GLB/GLTF to
support external material assignment (for ex, in Blender).
/*
       "extras": {
         "povray": {
           "material": "M_glass_green_water"
         }
       },
*/

3. In export file accuracy decreased to 6 digits to reduce the size
(thanks to 'kurtz le pirate').

4. Export format typo fixed (thanks to 'jr').

--  Known issues --

1. On import GLB/GLTF groups are not supported yes, so some issues
are possible (ex. 'Ingenuity Mars Helicopter.glb' from Mr).

-- In future releases --

1. Fixing GLB/GLTF groups issue

2. Extending materials library (please send your ideas and proposals
about content and organization).

3. Saving model in GLB format with materials tags to preserve materials
for future edit.

4. Passing Three.js camera position to POV scene for more precision
control.

5. Server-side rendering in preview window.

I will be very glad to get any feedback about the present state of the
project, ideas about new features and assistance in development
(at POV-Ray side).
-- 
YB

[Kenneth] Re: Online files converter [186 days 5 hours and 16 minutes ago]

Thu, 9 Oct 2025 00:25:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:

>
> I think that for very large meshes, the size of the converted file with
> 18 digits increases enormously without providing any additional precision.
>
> 4 or 6 digits should suffice and would reduce the size by more than four
> times (18/4=4.5).
>

In my own POV-ray-only stl-to-mesh converter-- not yet posted ;-) -- I came to
the same conclusion: that 4 or 5 digits were enough, and that more were simply
overkill. In my experience, some models' float values are written with much more
precision than is necessary.

HOWEVER, I am now thinking that it needs to be a 'dynamic' value-- based on the
number of triangles (or vertices) in the original file (whether .stl or .obj or
whatever type.)

Some files have a low-triangle count, others very high. As the number of
triangles increases, it usually means that they are smaller (for a given-size
object), to produce finer detail-- and thus require more precision in their
values. Otherwise, a 4-to-6 significant digit conversion process might create
unwanted duplicate values by truncating or rounding important digits. Here's an
example of my thinking:

an original float value in a LOW-triangle-count model:
69.5746344739 // probably overkill, since the triangles themselves are larger in
relation to the overall object. This could be reduced/rounded to 4 or 5 digits,
IMO, and still produce a perfectly adequate final model.

an original float value in a HIGH-triangle-count model:
69.5746344739 // all of those digits would probably be necessary, to prevent
duplicates due to rounding.

Then there are the middle cases between 'low' and 'high', of course.

I don't have a formula for creating such a dynamically-changing number of
significant digits-- because it is not yet clear as to what constitutes a low
triangle-count vs a higher one!-- but the idea might be worth pursuing.

[yesbird] Re: Online files converter [186 days 8 hours ago]

Wed, 8 Oct 2025 21:41:16 GMT

On 09/10/2025 00:03, Kenneth wrote:
> Does your analysis of Kurtz's file indicate duplicate *triangles*, or just
> duplicate vertices? Kurtz is converting his STL file to plain mesh AFAIU (not
> mesh2)-- and in such files there are necessarily many duplicate vertices, since
> they are shared among some triangles. I'm guessing that your own mesh2
> conversion code 'consolidates' those somehow-- resulting in fewer vertices
> overall.
> 
> My apologies; I was confusing your OBJ file discussion with STL file conversion.

I only answered the Kurtz's question about difference in of vertices in
our results. There is no *.inc file in Kurtz's zip, so I grepped obj.

> If so, is this consolidation or merging one of the 'efficiency' benefits of
> POV-ray's own mesh2 construct, or is it an extra operation that you added to
> your own conversion code?

My conversion process is following:
1. Calling OBJLoader() from Three.js library to load meshes into scene.

2. Call standard Three.js mergeVertices() method for each mesh on load
to build vertices index, that completely excludes duplicates.

3. Call my POVExporter(), which traverses scene, selects meshes and
saves data to model.ini as mesh2.

Very simple :)
-- 
YB

[Kenneth] Re: Online files converter [186 days 8 hours and 16 minutes ago]

Wed, 8 Oct 2025 21:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Does your analysis of Kurtz's file indicate duplicate *triangles*, or just
> duplicate vertices? Kurtz is converting his STL file to plain mesh AFAIU (not
> mesh2)--

My apologies; I was confusing your OBJ file discussion with STL file conversion.

[Kenneth] Re: Online files converter [186 days 8 hours and 36 minutes ago]

Wed, 8 Oct 2025 21:05:00 GMT

yesbird wrote:
> On 08/10/2025 19:10, kurtz le pirate wrote:
> > Sure ! A zip file with the OBJ file and my INC file.
>
> Thanks, merging is the reason, I see a lot of duplicates here:
> grep -w v pingouin.obj  | tail -n 20
> v 0.023851 0.00175495 0.0374573
> v 0.023851 0.00175495 0.0374573
> v 0.023851 0.00175495 0.0374573
> (etc.)

Does your analysis of Kurtz's file indicate duplicate *triangles*, or just
duplicate vertices? Kurtz is converting his STL file to plain mesh AFAIU (not
mesh2)-- and in such files there are necessarily many duplicate vertices, since
they are shared among some triangles. I'm guessing that your own mesh2
conversion code 'consolidates' those somehow-- resulting in fewer vertices
overall.

If so, is this consolidation or merging one of the 'efficiency' benefits of
POV-ray's own mesh2 construct, or is it an extra operation that you added to
your own conversion code?

[yesbird] Re: Online files converter [186 days 12 hours and 23 minutes ago]

Wed, 8 Oct 2025 17:18:24 GMT

On 08/10/2025 20:00, yesbird wrote:
> On 08/10/2025 19:10, kurtz le pirate wrote:
>> Sure ! A zip file with the OBJ file and my INC file.
> 
> Thanks, merging is the reason, I see a lot of duplicates here ...

Z-Brush also report about unused vertices, please find optimized version
in attachment.
-- 
YB

[yesbird] Re: Online files converter [186 days 12 hours and 40 minutes ago]

Wed, 8 Oct 2025 17:01:02 GMT

On 08/10/2025 19:10, kurtz le pirate wrote:
> Sure ! A zip file with the OBJ file and my INC file.

Thanks, merging is the reason, I see a lot of duplicates here:
grep -w v pingouin.obj  | tail -n 20
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
-------------------------------

PS: Attached pingouin inspired by Terminator-2 ).
-- 
YB

[kurtz le pirate] Re: Online files converter [186 days 13 hours and 30 minutes ago]

Wed, 8 Oct 2025 16:10:55 GMT

On 08/10/2025 17:58, yesbird wrote:
> On 08/10/2025 18:29, kurtz le pirate wrote:
>> Have you noticed any improvements ?
> 
> Yes, I am working hard and updating it daily, fixing the bugs and
> implementing new features. Now working on material library and improving
> studio environment.
> 
>> Another thing about my converter. I find 18,531 vertices, while you 
>> only have 952.
> 
> I do merging on load, maybe this is the reason. Could you please send me
> your file for testing ? Good bug report is the half of a successful fix
> :).


Sure ! A zip file with the OBJ file and my INC file.


>> I think that for very large meshes, the size of the converted file 
>> with 18 digits increases enormously without providing any additional 
>> precision.
>>
>> 4 or 6 digits should suffice and would reduce the size by more than 
>> four times (18/4=4.5).
> 
> Agree with you and have already been included it in my TODO list.
> 
>>
>> Good job ;)
> 
> Thanks for the kind words :).
> -- 
> YB
> 
> 





-- 
kurtz le pirate
compagnie de la banquise

[yesbird] Re: Online files converter [186 days 13 hours and 43 minutes ago]

Wed, 8 Oct 2025 15:58:08 GMT

On 08/10/2025 18:29, kurtz le pirate wrote:
> Have you noticed any improvements ?

Yes, I am working hard and updating it daily, fixing the bugs and
implementing new features. Now working on material library and improving
studio environment.

> Another thing about my converter. I find 18,531 vertices, while you only 
> have 952.

I do merging on load, maybe this is the reason. Could you please send me
your file for testing ? Good bug report is the half of a successful fix
:).

> I think that for very large meshes, the size of the converted file with 
> 18 digits increases enormously without providing any additional precision.
> 
> 4 or 6 digits should suffice and would reduce the size by more than four 
> times (18/4=4.5).

Agree with you and have already been included it in my TODO list.

> 
> Good job ;)

Thanks for the kind words :).
--
YB

[kurtz le pirate] Re: MathView - math surfaces editor with POV-Ray... [186 days 13 hours and 56 minutes ago]

Wed, 8 Oct 2025 15:45:11 GMT

On 06/10/2025 16:58, Mr wrote:

> 
> Again, your whole site is blocked from behind my corporate proxy, so I can't but
> it looks like a very good idea.(I suppose it may be blocked because of being
> http rather than https?)
> 

This is surely due to the fact that your company is unable to decrypt 
pages (TLS 1.3 and/or SHA-256 ECDSA signature) with the YesBird website 
certificates.

SSL/TLS certificates and authentication chains should be installed on 
your company's security equipment... I don't think they would approve.

No decryption -> no analysis -> blocking :(

-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Online files converter [186 days 14 hours and 12 minutes ago]

Wed, 8 Oct 2025 15:29:12 GMT

On 05/10/2025 14:58, yesbird wrote:
> 
> Thanks for feedback, could you please provide a little bit more
> details - why can't you convert them ? And who else can't ?
> Please send me your OBJ and content of _console_ tab (F12).

Hum ... After another attempt today, my file loaded correctly and my 
pingoin appears correctly.

Have you noticed any improvements ?

Another thing about my converter. I find 18,531 vertices, while you only 
have 952.

I think that for very large meshes, the size of the converted file with 
18 digits increases enormously without providing any additional precision.

4 or 6 digits should suffice and would reduce the size by more than four 
times (18/4=4.5).

Good job ;)

> The project is in beta state, so debug information is highly
> appreciated.

-- 
kurtz le pirate
compagnie de la banquise

[yesbird] Re: Online files converter [188 days 5 hours and 31 minutes ago]

Tue, 7 Oct 2025 00:09:55 GMT

On 28/09/2025 01:27, yesbird wrote:
> Finally, after two sleepless nights I finished a web application that
> converts obj, fbx, glb, gltf, stl formats to mesh2 ...

Another update is ready - now materials can be assigned to different
parts of the model. The process is not convenient yet, but enough for
testing.
--
YB

[yesbird] Re: Online files converter [188 days 13 hours and 51 minutes ago]

Mon, 6 Oct 2025 15:50:27 GMT

On 06/10/2025 18:16, Mr wrote:
>  From what I understand of your idea, it would aim to provide a totally different
> pipeline than POV@Ble, and it would actually not consist of a POV@Ble
> modification, but rather an addition to the e.g. gltf exporter. I can help you
> reach out to the relevant dev if you want to make him such a proposition, but it
> should be really refined as he's like one of the 5 most busy Blender devs.
> (sweat); and also his code one of the highest standard.Yes, exactly, this solution
has no relation to POV@Ble, it's some kind
of alternative. This idea came to me only this morning, so I need
to think hard about details and look up the modern Blender interface to
make proposition well.

Many thanks for your support, I will get back to you in 1-2 days.
-- 
YB

[yesbird] Re: Online files converter [188 days 14 hours ago]

Mon, 6 Oct 2025 15:41:22 GMT

On 06/10/2025 18:07, Mr wrote:
> Your screenshot shows great materials, but I don't understand why not use the
> current POV custom code hooks already featured directly in POV@Ble they append
> the pov code at top of exported POV files and add the declared textures to the
> exported pov objects. A sample library of such pov mats was even made available
> in the old wiki and is planned to be shipped again l### [at] erIf you find it more simple
and POV@Ble work good - then, yes, this is a
solution. I am always looking for different approaches, to choose
the best.
-- 
YB

[Mr] Re: Online files converter [188 days 14 hours and 21 minutes ago]

Mon, 6 Oct 2025 15:20:00 GMT

yesbird wrote:
> On 30/09/2025 12:07, Mr wrote:
> > I think you should look at GIS packages (QGis/OpenSceneGraph...), ...Sorry for
off-topic, but I read that you are w
orking with Blender
> (POV@Ble). I have idea about effective conversion from Blender to
> POV-Ray: If only Blender can work with glTF or GLB file's .extras
> property that can store arbitrary JSON content, then we can use it
> to store material name and then convert it to POV with my converter.
>
> It's possible not to use a web-based GUI version, but to create a
> command line utility running under node.js.
>
> We can use for the start this impressive materials collection - the
> royal gift from Mike Miller:
> https://drive.google.com/file/d/1PncYI4G2ssqIXjK1rMej-PgAZ9Gnatz1/view?usp=sharing
>
> What is your opinion ?
> --
> YB

From what I understand of your idea, it would aim to provide a totally different
pipeline than POV@Ble, and it would actually not consist of a POV@Ble
modification, but rather an addition to the e.g. gltf exporter. I can help you
reach out to the relevant dev if you want to make him such a proposition, but it
should be really refined as he's like one of the 5 most busy Blender devs.
(sweat); and also his code one of the highest standard.

[Mr] Re: Online files converter [188 days 14 hours and 31 minutes ago]

Mon, 6 Oct 2025 15:10:00 GMT

yesbird wrote:
> On 30/09/2025 12:07, Mr wrote:
> > I think you should look at GIS packages (QGis/OpenSceneGraph...), ...Sorry for
off-topic, but I read that you are w
orking with Blender
> (POV@Ble). I have idea about effective conversion from Blender to
> POV-Ray: If only Blender can work with glTF or GLB file's .extras
> property that can store arbitrary JSON content, then we can use it
> to store material name and then convert it to POV with my converter.
>
> It's possible not to use a web-based GUI version, but to create a
> command line utility running under node.js.
>
> We can use for the start this impressive materials collection - the
> royal gift from Mike Miller:
> https://drive.google.com/file/d/1PncYI4G2ssqIXjK1rMej-PgAZ9Gnatz1/view?usp=sharing
>
> What is your opinion ?
> --
> YB

Your screenshot shows great materials, but I don't understand why not use the
current POV custom code hooks already featured directly in POV@Ble they append
the pov code at top of exported POV files and add the declared textures to the
exported pov objects. A sample library of such pov mats was even made available
in the old wiki and is planned to be shipped again later.

[yesbird] Re: MathView - math surfaces editor with POV-Ray... [188 days 14 hours and 34 minutes ago]

Mon, 6 Oct 2025 15:06:55 GMT

On 06/10/2025 17:58, Mr wrote:
> Again, your whole site is blocked from behind my corporate proxy, so I can't but
> it looks like a very good idea.(I suppose it may be blocked because of being
> http rather than https?)
Sorry, but you are the only, who reports access problems, site works
via https. I don't know a policy of your corporation, it's better to ask
your admins.

Thanks for the support, I believe that idea is really promising and
working hard on implementation.
-- 
YB

[Mr] Re: MathView - math surfaces editor with POV-Ray... [188 days 14 hours and 41 minutes ago]

Mon, 6 Oct 2025 15:00:00 GMT

yesbird wrote:
> On 06/10/2025 15:29, Mr wrote:
> > Hi, I had to use the phone again, and the material thumnails tend to cover all
> > of the rest... But the math formulas display looks neat !
> Thank you for feedback, but this application definitely is not for
> phones, it also will not work on a calculators or refrigerators :).
>
> It assumes a monitor with HD(1920x1080) resolution, please try it
> this way.
> --
> YB

Again, your whole site is blocked from behind my corporate proxy, so I can't but
it looks like a very good idea.(I suppose it may be blocked because of being
http rather than https?)

[Bald Eagle] Re: MathView - math surfaces editor with POV-Ray... [188 days 14 hours and 51 minutes ago]

Mon, 6 Oct 2025 14:50:00 GMT

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

> "user input"

So would we classify that as input or output?
Or a "pipe" | from one to the other?  :D

Clearly this is a fertile topic to explore once I digest its full import.

- BE

[Bald Eagle] Re: Online files converter [188 days 14 hours and 56 minutes ago]

Mon, 6 Oct 2025 14:45:00 GMT

Just following up on this,

I think that for your parametric equations, it would be trivial to have an
export option for these, since they are extremely simply to output as quads of
two triangles.

Isosurfaces would be a lot more difficult I think - there has been a long
history of trying to implement meshification of these objects.

Now, perhaps if there are libraries at your disposal for things like convex
hull, it might be easy enough to provide at least that, so that there was some
data for users to experiment with and think about various approaches to more
completely represent such surfaces prior to render phase.

- BW

[Ilya Razmanov] Re: MathView - math surfaces editor with POV-Ray... [188 days 15 hours and 8 minutes ago]

Mon, 6 Oct 2025 14:33:09 GMT

On 06.10.2025 15:39, yesbird wrote:

> phones, it also will not work on a calculators or refrigerators :).

I bet on lavatories. It's only a matter of time. And some user input 
devices modification.

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

[yesbird] Re: Online files converter [188 days 15 hours and 23 minutes ago]

Mon, 6 Oct 2025 14:18:12 GMT

On 30/09/2025 12:07, Mr wrote:
> I think you should look at GIS packages (QGis/OpenSceneGraph...), ...Sorry for
off-topic, but I read that you are working with Blender
(POV@Ble). I have idea about effective conversion from Blender to
POV-Ray: If only Blender can work with glTF or GLB file's .extras
property that can store arbitrary JSON content, then we can use it
to store material name and then convert it to POV with my converter.

It's possible not to use a web-based GUI version, but to create a
command line utility running under node.js.

We can use for the start this impressive materials collection - the
royal gift from Mike Miller:
https://drive.google.com/file/d/1PncYI4G2ssqIXjK1rMej-PgAZ9Gnatz1/view?usp=sharing

What is your opinion ?
-- 
YB

[yesbird] Re: MathView - math surfaces editor with POV-Ray... [188 days 17 hours and 2 minutes ago]

Mon, 6 Oct 2025 12:39:18 GMT

On 06/10/2025 15:29, Mr wrote:
> Hi, I had to use the phone again, and the material thumnails tend to cover all
> of the rest... But the math formulas display looks neat !
Thank you for feedback, but this application definitely is not for
phones, it also will not work on a calculators or refrigerators :).

It assumes a monitor with HD(1920x1080) resolution, please try it
this way.
-- 
YB

[Mr] Re: MathView - math surfaces editor with POV-Ray... [188 days 17 hours and 11 minutes ago]

Mon, 6 Oct 2025 12:30:00 GMT

yesbird wrote:
> Hi, all !
> I would like to show you another source of geometry for POV-Ray:
> https://mathview.yesbird.online
>
> I was enchanted by math surfaces from my school years, always like to
> play with different math packages, including Mathlab, Mathematica and
> now Wolfram Alpha.
>
> Inspired by following sources:
> https://virtualmathmuseum.org/
> https://3d-xplormath.org/
> https://github.com/parisolab/mathmod
>
> I decided to write an online tool for exploring surfaces with simple and
> convenient GUI, rich visual representation and export to most popular
> modern formats (POV mesh2 also supported). For those who have an XR
> headset, I made available XR mode.
>
> Now all main functionality is completed and I am starting to fill the
> collection with the most interesting and attractive surfaces.
>
> How to use:
> -  Combine 6 materials and 18 textures for desired visual effect
> -  Click twice on the color map icon to change projection
> -  Edit surface parameters
> -  Edit functions of surfaces, that has a 'pen' mark
> -  Shift surface parameters in 'Settings' to see changes in real time
> -  Take screenshots by clicking 'Camera' icon
> -  Download geometry in 'OBJ' or 'POV' format
> -  Enter XR mode by clicking 'Box' icon
>
> Also there is a short description available by clicking (?) icon.
>
> For POV-Ray users:
> Download scene template with complete set of textures from here:
> https://mathview.yesbird.online/data/templates/scene.zip
>
> In MathView: select desired surface, download data in POV format,
> save 'surface.ini' file in directory where 'scene.pov' is located.
>
> In POV-Ray: render scene.pov with desired settings, try different image
> maps, located in 'textures' directory.
>
> I will be glad to get any kind of feedback from you, including
> suggestions about surfaces to add.
> --
> YB

Hi, I had to use the phone again, and the material thumnails tend to cover all
of the rest... But the math formulas display looks neat !

[yesbird] Re: MathView - math surfaces editor with POV-Ray... [189 days 6 hours and 19 minutes ago]

Sun, 5 Oct 2025 23:22:13 GMT

On 06/10/2025 02:13, yesbird wrote:
> I would like to show you another source of geometry for POV-Ray:
> https://mathview.yesbird.online
Rendering example attached.
-- 
YB

[yesbird] MathView - math surfaces editor with POV-Ray sup... [189 days 6 hours and 28 minutes ago]

Sun, 5 Oct 2025 23:13:04 GMT

Hi, all !
I would like to show you another source of geometry for POV-Ray:
https://mathview.yesbird.online

I was enchanted by math surfaces from my school years, always like to
play with different math packages, including Mathlab, Mathematica and
now Wolfram Alpha.

Inspired by following sources:
https://virtualmathmuseum.org/
https://3d-xplormath.org/
https://github.com/parisolab/mathmod

I decided to write an online tool for exploring surfaces with simple and
convenient GUI, rich visual representation and export to most popular
modern formats (POV mesh2 also supported). For those who have an XR 
headset, I made available XR mode.

Now all main functionality is completed and I am starting to fill the
collection with the most interesting and attractive surfaces.

How to use:
-  Combine 6 materials and 18 textures for desired visual effect
-  Click twice on the color map icon to change projection
-  Edit surface parameters
-  Edit functions of surfaces, that has a 'pen' mark
-  Shift surface parameters in 'Settings' to see changes in real time
-  Take screenshots by clicking 'Camera' icon
-  Download geometry in 'OBJ' or 'POV' format
-  Enter XR mode by clicking 'Box' icon

Also there is a short description available by clicking (?) icon.

For POV-Ray users:
Download scene template with complete set of textures from here:
https://mathview.yesbird.online/data/templates/scene.zip

In MathView: select desired surface, download data in POV format,
save 'surface.ini' file in directory where 'scene.pov' is located.

In POV-Ray: render scene.pov with desired settings, try different image
maps, located in 'textures' directory.

I will be glad to get any kind of feedback from you, including
suggestions about surfaces to add.
--
YB

[yesbird] Re: Online files converter [189 days 13 hours and 59 minutes ago]

Sun, 5 Oct 2025 15:42:12 GMT

On 05/10/2025 12:34, kurtz le pirate wrote:
> I think you still have some work to do to refine all this;
Sure, the reason of OBJ loading issues was lack of 'mtl' file,
OBJ materials is not supported yes, will implement it later.
I made a fix to just ignore them.

PS: Frog is nice ! (attached)
--
YB

[yesbird] Re: Online files converter [189 days 16 hours and 42 minutes ago]

Sun, 5 Oct 2025 12:59:00 GMT

On 05/10/2025 12:34, kurtz le pirate wrote:
> Well done on the initiative, but like others here, I can't convert OBJ 
> files. My OBJ files are fine. With my silly Perl script, conversion to 
> POV works fine.
> 
> I think you still have some work to do to refine all this;

Thanks for feedback, could you please provide a little bit more
details - why can't you convert them ? And who else can't ?
Please send me your OBJ and content of _console_ tab (F12).

The project is in beta state, so debug information is highly
appreciated.
-- 
YB

[kurtz le pirate] Re: Online files converter [189 days 20 hours and 7 minutes ago]

Sun, 5 Oct 2025 09:34:06 GMT

On 28/09/2025 00:27, yesbird wrote:
> Finally, after two sleepless nights I finished a web application that
> converts obj, fbx, glb, gltf, stl formats to mesh2:
> https://povlab.yesbird.online/all2pov
> 
> I tested it only on a limited number of files, so some issues
> (especially related to displaying a model) are possible, testingÂ  now in
> progress. Please send any kind of feedback: bug reports, suggestions,
> requests to implement, etc.


Well done on the initiative, but like others here, I can't convert OBJ 
files. My OBJ files are fine. With my silly Perl script, conversion to 
POV works fine.


I think you still have some work to do to refine all this;



ps: yes, my Firefox 143.0.4-64 is compatible with WebGL 1 & 2.




-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Online files converter [190 days 5 hours and 1 minute ago]

Sun, 5 Oct 2025 00:40:00 GMT

yesbird wrote:
> On 05/10/2025 01:19, Bald Eagle wrote:
> > Just for kicks, I searched Thingiverse for Povray . .
> Chainmaker is rather interesting ...
>
> Btw, Bill, I need your advice. I am working on online viewer of math
> objects (screenshot attached):
> https://mathview.yesbird.online/
> and now it has export only to OBJ.
>
> Is it worth adding a POV exporter to it, taking in account that POV-Ray
> already has a powerful library for generating math surfaces ?

Well,

All I can say is that although we have things like parametric, isosurface, and
polynomial - what we don't have is a visual modeler for such things.

There does exist MathMod - which can be quite cryptic, and Desmos - which can
help visualize equations.  But neither have any sort of export feature.

I'm a fan of the mathematical objects - it's probably one of my favorite things
to play with and render - but after over a dozen years of experience, I'd say
that there are usually only a few select shapes that have real, broad utility.

sphere, cylinder, torus, Dupin cyclide, etc.

Now, on the other end of the spectrum, when you need a specialized shape, and it
has to have very exacting dimensions and attributes, then parametrics and
implicit isosurfaces are probably the only things that will fit the bill -
especially when combined with surface displacement.
And those things can be VERY difficult to visualize.

I really like what you're doing, and there are things that I would want, and
would be great to experiment with.  But I don't know what sort of workload is
necessary to make them happen, or what other projects you have to wrap up.

So, ultimately, I'd say that you're going to have to decide for yourself.

We can discuss this more, but I'll leave you with all of that to think about.

- BW

[yesbird] Re: Online files converter [190 days 6 hours and 36 minutes ago]

Sat, 4 Oct 2025 23:04:57 GMT

On 05/10/2025 01:19, Bald Eagle wrote:
> Just for kicks, I searched Thingiverse for Povray . .
Chainmaker is rather interesting ...

Btw, Bill, I need your advice. I am working on online viewer of math
objects (screenshot attached):
https://mathview.yesbird.online/
and now it has export only to OBJ.

Is it worth adding a POV exporter to it, taking in account that POV-Ray
already has a powerful library for generating math surfaces ?

Remembering quote by Steve Jobs: "Deciding what not to do is as
important as deciding what to do" ? :)
--
YB

[Bald Eagle] Re: Online files converter [190 days 7 hours and 21 minutes ago]

Sat, 4 Oct 2025 22:20:00 GMT

Just for kicks, I searched Thingiverse for Povray . . .

Rick's Chainmaker for POVRay
https://www.thingiverse.com/thing:726783

Zeycus' Abstract Chess Set
Chess set I designed in 2001, originally in PovRay.
Recently used Openscad to create the STL file.
https://www.thingiverse.com/thing:952393


Superellipsoid
https://www.thingiverse.com/thing:12419

Supershape
https://www.thingiverse.com/thing:12770

Cylindrical container holder rendered in POV-Ray
https://www.thingiverse.com/thing:1932960

- BE

[yesbird] Re: Online files converter [190 days 8 hours and 16 minutes ago]

Sat, 4 Oct 2025 21:25:25 GMT

On 04/10/2025 23:29, Maetes wrote:
> If you could extract the textures also, I would bring the Mars-Rover or
> Ingenuity to life.

Use search, Luke !
https://products.aspose.app/3d/extractor/glb
And see attachment ... :).
-- 
YB

[yesbird] Re: Online files converter [190 days 8 hours and 25 minutes ago]

Sat, 4 Oct 2025 21:16:13 GMT

On 04/10/2025 23:29, Maetes wrote:
> Yes, "something" like that.
> But instead the code-block many sliders and checkboxes and select-boxes.
> And only one or two object (box and sphere) to show the texture.
> And a download-button to get the texture.
Don't you mixing a texture and material ?
http://www.povray.org/documentation/view/3.60/324/
http://www.povray.org/documentation/view/3.6.1/331/

In any case implementation will not be difficult - I guess, you can try
it yourself. You will only need to install node.js and master
javascript, also PHP alittle.
> This treejs looks indeed very promising, maybe I'll give it a try for my own
> website.
Yes, it's really cool. Almost standard-de-facto for WegGL/WebGPU works
now.
> 
> Your all2mesh-tool:
Now it's "POV-Ray studio" :).
> If you could extract the textures also, I would bring the Mars-Rover or
> Ingenuity to life.
Maybe later, after finishing two active projects.
-- 
YB

[Maetes] Re: Online files converter [190 days 9 hours and 11 minutes ago]

Sat, 4 Oct 2025 20:30:00 GMT

yesbird wrote:
> On 04/10/2025 01:30, Maetes wrote:
> >
> > That's why I thought about a web interface that offers select boxes and sliders
> > for the different settings, re-renders at command, and displays the image.
> >
> Btw, last year I did this experimental project for server-side
> rendering: https://povlab.yesbird.online/
>
> Maybe it was the first step toward what you are dreaming about ?
> :)
> --
> YB

Yes, "something" like that.
But instead the code-block many sliders and checkboxes and select-boxes.
And only one or two object (box and sphere) to show the texture.
And a download-button to get the texture.

This treejs looks indeed very promising, maybe I'll give it a try for my own
website.

Your all2mesh-tool:
If you could extract the textures also, I would bring the Mars-Rover or
Ingenuity to life.
The tool is nice, maybe I can use it sometimes, especially for some NASA-Stuff.

m

[yesbird] Re: Online files converter [191 days 6 hours and 5 minutes ago]

Fri, 3 Oct 2025 23:36:47 GMT

On 04/10/2025 01:30, Maetes wrote:
> 
> That's why I thought about a web interface that offers select boxes and sliders
> for the different settings, re-renders at command, and displays the image.
>
Btw, last year I did this experimental project for server-side
rendering: https://povlab.yesbird.online/

Maybe it was the first step toward what you are dreaming about ?
:)
-- 
YB

[yesbird] Re: Online files converter [191 days 6 hours and 7 minutes ago]

Fri, 3 Oct 2025 23:34:11 GMT

On 04/10/2025 01:30, Maetes wrote:
> That's why I thought about a web interface that offers select boxes and sliders
> for the different settings, re-renders at command, and displays the image.Btw, last
year I did this experimental project for server-side
rendering, maybe it was the first step toward what you are dreaming
about ? :)
--
YB

[yesbird] Re: Online files converter [191 days 6 hours and 40 minutes ago]

Fri, 3 Oct 2025 23:01:21 GMT

On 04/10/2025 01:30, Maetes wrote:
> It is very cumbersome and annoying to try out textures directly in the text file
> with Povray.
> ...
Yes, I know, but I did not see any online GUI anywhere.
I am thinking about something like this, but implementation could be
tricky. As far as I know, Blender supports POV-Ray and has a GUI, but I
don't know details, preferring C4D.
-- 
YB

[yesbird] Re: Online files converter [191 days 6 hours and 49 minutes ago]

Fri, 3 Oct 2025 22:52:34 GMT

On 04/10/2025 01:22, Maetes wrote:
> That's an outstanding support here :)
Thanks, we are pleased to help :)

> But have problems with this model (see pic):
> https://science.nasa.gov/3d-resources/ingenuity-mars-helicopter/
> 
> Is it an error in the glb-file?
No, the file is OK, you can check this yourself here:
https://threejs.org/editor/

The project in beta state now, so some issues are possible,
will fix it soon. Many thanks for testing and bug reports -
I am really need them.

> 
> And is it possible to extract the textures also?
Interesting, I guess yes, will try it little bit later.
Right now I am working on POV-Ray materials support.

> 
> 2 new ideas:
> - save the pov-lines how to use the code in a docu-block in the upper part of
> the file
> - save the name of the original file also somewhere (have now many files in my
> download-folder like "model (4).inc" and dont know whats in it.
Good idea, saved it to my TODO list.

Wishing well.
-- 
YB

[Maetes] Re: Online files converter [191 days 7 hours and 6 minutes ago]

Fri, 3 Oct 2025 22:35:00 GMT

yesbird wrote:
> >
> > Do you know an online-tool to create textures for Povray?
>
> No, but it depends on what do you mean by 'textures for Povray' ?
> As far as I know Povray uses ordinary bitmaps in image_map
> instruction: https://www.povray.org/documentation/view/3.60/337/
>

It is very cumbersome and annoying to try out textures directly in the text file
with Povray.
You set something in the texure, render the image, change bump-values or colours
or something again, render by cmd-line, still don't look good, back into the
text file...

That's why I thought about a web interface that offers select boxes and sliders
for the different settings, re-renders at command, and displays the image.

I think that would be much faster and more relaxed.
If something similar already exists, just let me know the website.

ma

[Maetes] Re: Online files converter [191 days 7 hours and 16 minutes ago]

Fri, 3 Oct 2025 22:25:00 GMT

yesbird wrote:
>
> 2. By advice of Paul Bourke, scene metrics at the top of model.inc file:
> 3. Wireframe model shading.
>
> How to use:
> All meshes in 'model.inc' have names surface*, numbered from 1.
> At the end of the file there is a 'union', that combines them together.
> ...


That's an outstanding support here :)

Tested it, and it works.
Tried the Hubble, the Voyager, and there they are.
Nice Idea to save all parts in different variables.

But have problems with this model (see pic):
https://science.nasa.gov/3d-resources/ingenuity-mars-helicopter/

Is it an error in the glb-file?

And is it possible to extract the textures also?

2 new ideas:
- save the pov-lines how to use the code in a docu-block in the upper part of
the file
- save the name of the original file also somewhere (have now many files in my
download-folder like "model (4).inc" and dont know whats in it.

ma

[yesbird] Re: Online files converter [192 days 8 hours and 9 minutes ago]

Thu, 2 Oct 2025 21:32:15 GMT

Just now I posted anÂ update to converter, that includes:

1. Load and export complete scene (all meshes containedÂ in the file).
2. By advice of Paul Bourke, scene metrics at the top of model.inc file:
  Â  center and radius of bounding sphere, bounding box coordinates.
3. Wireframe model shading.

How to use:
All meshes in 'model.inc' have names surface*, numbered from 1.
At the end of the file there is a 'union', that combines them together.
//----------- Sample scene (attached) ----------------------------------
#version 3.7;
#include "model.inc"

global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}
#declare cam = camera { perspective angle 55
 Â  Â  Â  Â  Â  Â 
Â  Â  Â  Â  Â  Â  location
Â <RADIUS, RADIUS, RADIUS> * 1.5
 Â  Â  Â  Â  Â  Â 
Â  Â  Â  Â  Â  Â  right
Â  Â  x * image_width / image_height
 Â  Â  Â  Â  Â  Â 
Â  Â  Â  Â  Â  Â  look_at
Â  CENTER}
camera{cam}
light_source{< 3000,3000,-3000> color rgb <1.0, 1.0, 1.0>}
//-----------------------------------------------------------------------

TestingÂ and any kind of feedback are highly appreciatedÂ :).
-- 
YB

[yesbird] Re: Online files converter [192 days 18 hours and 47 minutes ago]

Thu, 2 Oct 2025 10:54:10 GMT

On 02/10/2025 10:17, Maetes wrote:
> handling of multiple meshes would be a nice feature :)
> Without it I have to learn how to convert the files first.

No doubt, this is the first position in my TODO list :).

> 
> Your Website and the GUI of all2mesh looks nice.
> Have checked it out, also the other tools.
> Maybe some words about them, small description what they are doing?
> And who has created them?

If you about https://yesbird.online/, then this is my portfolio,
"Yesbird studio" - it's me :). Tooltips will appear on cards hovering,
all (almost) applications have some help.

> 
> Do you know an online-tool to create textures for Povray?

No, but it depends on what do you mean by 'textures for Povray' ?
As far as I know Povray uses ordinary bitmaps in image_map
instruction: https://www.povray.org/documentation/view/3.60/337/

Btw, I am going to implement a line of online tools for POV-Ray:
spline, prizm and SOR editors will be the first.

> I've already thought about programming something like this myself.

In this case you can check https://threejs.org - this is the great tool
with very friendly support.

Wish you good luck with it !
-- 
YB

[yesbird] Re: Online files converter [192 days 19 hours and 12 minutes ago]

Thu, 2 Oct 2025 10:29:06 GMT

On 02/10/2025 10:11, Maetes wrote:
> yesbird wrote:
> 
>>> Thanks for feedback, to fix GLB issue I need to add one more compression
>>> feature.
>>
>> 'Crab Nebula.glb' works fine now ( see attachment), please try it again.
>> --
>> YB
> 
> AsyncLoader.js:51 Error: THREE.GLTFLoader: No DRACOLoader instance provided.
>      at new GLTFDracoMeshCompressionExtension (GLTFLoader.js:1922:10)
>      at GLTFLoader.parse (GLTFLoader.js:400:37)
>      at Object.onLoad (GLTFLoader.js:245:11)
>      at three.module.js:44568:38
> _onError @ GLTFLoader.js:225
> AsyncLoader.js:37 Problem loading:
> uploads/d91ecd2052b7fe17892df46e1a6d97a43a76a4f8/Crab Nebula.glb
> 

Thanks for feedback, just checked - 'Crab Nebula.glb' still works
fine. Please try to clear browser's cache.
-- 
YB

[Maetes] Re: Online files converter [192 days 22 hours and 21 minutes ago]

Thu, 2 Oct 2025 07:20:00 GMT

yesbird wrote:

> The reason is multiple meshes, contained in this scene, but conversion
> is possible only for one. Merging all of them  will produce complete
> model.
> --
> YB

handling of multiple meshes would be a nice feature :)
Without it I have to learn how to convert the files first.

Your Website and the GUI of all2mesh looks nice.
Have checked it out, also the other tools.
Maybe some words about them, small description what they are doing?
And who has created them?

Do you know an online-tool to create textures for Povray?
I've already thought about programming something like this myself.

Greetings from Cologne,
Ma

[Maetes] Re: Online files converter [192 days 22 hours and 26 minutes ago]

Thu, 2 Oct 2025 07:15:00 GMT

yesbird wrote:

> > Thanks for feedback, to fix GLB issue I need to add one more compression
> > feature.
>
> 'Crab Nebula.glb' works fine now ( see attachment), please try it again.
> --
> YB

AsyncLoader.js:51 Error: THREE.GLTFLoader: No DRACOLoader instance provided.
    at new GLTFDracoMeshCompressionExtension (GLTFLoader.js:1922:10)
    at GLTFLoader.parse (GLTFLoader.js:400:37)
    at Object.onLoad (GLTFLoader.js:245:11)
    at three.module.js:44568:38
_onError @ GLTFLoader.js:225
AsyncLoader.js:37 Problem loading:
uploads/d91ecd2052b7fe17892df46e1a6d97a43a76a4f8/Crab Nebula.glb

[yesbird] Re: Online files converter [193 days 5 hours and 18 minutes ago]

Thu, 2 Oct 2025 00:23:43 GMT

On 02/10/2025 00:43, Maetes wrote:
> Only this model showed something, unfortunately not more than a part of the
> Antenna-Boom.
> https://science.nasa.gov/3d-resources/viking-lander/

The reason is multiple meshes, contained in this scene, but conversion
is possible only for one. Merging all of them  will produce complete
model.
-- 
YB

[yesbird] Re: Online files converter [193 days 6 hours and 20 minutes ago]

Wed, 1 Oct 2025 23:21:39 GMT

On 02/10/2025 01:56, yesbird wrote:
> On 02/10/2025 00:43, Maetes wrote:
>>
>> I just tried it with some models from NASA.
>> glb and stl, none worked for me.
> 
> Thanks for feedback, to fix GLB issue I need to add one more compression
> feature.

'Crab Nebula.glb' works fine now ( see attachment), please try it again.
--
YB

[yesbird] Re: Online files converter [193 days 6 hours and 45 minutes ago]

Wed, 1 Oct 2025 22:56:12 GMT

On 02/10/2025 00:43, Maetes wrote:
> 
> I just tried it with some models from NASA.
> glb and stl, none worked for me.

Thanks for feedback, to fix GLB issue I need to add one more compression
feature.

'Crab Nebula (disc).stl' works fine for me (see attachment).  Can you
please press F12 and send me a content of 'Console' tab ?
-- 
YB

[Maetes] Re: Online files converter [193 days 7 hours and 56 minutes ago]

Wed, 1 Oct 2025 21:45:00 GMT

I just tried it with some models from NASA.
glb and stl, none worked for me.

https://science.nasa.gov/3d-resources/crab-nebula/
https://science.nasa.gov/3d-resources/hubble-space-telescope-a/

tried also cassini, DS1, EVA, and some others.
Chromium (Rasberry Pi) and Firefox.

Only this model showed something, unfortunately not more than a part of the
Antenna-Boom.
https://science.nasa.gov/3d-resources/viking-lander/

ma

[yesbird] Re: Online files converter [194 days 6 hours and 14 minutes ago]

Tue, 30 Sep 2025 23:27:08 GMT

On 30/09/2025 22:55, Kenneth wrote:
> 
> Your hard work is very much appreciated.
> 
I am very glad. Btw, I added a floor grid for better visual experience.
Please don't forget to share your renderings here ).
-- 
YB

[Kenneth] Re: Online files converter [194 days 9 hours and 41 minutes ago]

Tue, 30 Sep 2025 20:00:00 GMT

yesbird wrote:
> On 30/09/2025 15:04, Kenneth wrote:
> >
> > My suggestion would be to allow a *choice* of downloading the mesh2 model as
> > 'smooth triangles' or as just flat un-smoothed ones.
> >
> Agree with you and this is already works right "out of the box": just
> select the "Flat shading" checkbox and _then_ download a model.

Oh, I didn't know! That's great-- and I am even MORE impressed that you already
implemented it. Thanks for the tip!

Your hard work is very much appreciated.

[Kenneth] Re: Online files converter [194 days 9 hours and 51 minutes ago]

Tue, 30 Sep 2025 19:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> >...and new downloads could overwrite the previous ones
> > if we are lazy :-O
>
> My browsers usually append a (1), (2), .. (n) to the filename automatically.
> Maybe you have similar in settings?
>

Ah, you're right, and I had forgotten; Firefox/Windows does that as well. I just
tested it again. (It has been a long time since I downloaded multiple copies of
the same file name.)

But uniquely-numbered downloads from yesbird would still be useful :-D

[yesbird] Re: Online files converter [194 days 15 hours and 34 minutes ago]

Tue, 30 Sep 2025 14:07:18 GMT

On 30/09/2025 15:04, Kenneth wrote:
> That is really a fabulous service, yesbird! I just used it to convert two
> binary-file STL models (from Thingiverse) that I have been wanting to see in
> POV-ray for a long time.
> ...
Many thanks, I am glad that you find it useful.

> 
> Your site works beautifully, and the upload/download speeds for me are VERY
> fast. I am amazed at how quickly you wrote code to accomplish this task. Thank
> you!
The reason is a set of tools I am using: HTML5/JS/Three.js.
After a long time working with C++/Linux I feel like playing Lego toys
comparing to complicated real-world mechanics :).

> 
> I know that you are busy with other things, but I have several small(?)
> suggestions:
This is very much in time. It will help me to make this service better,
thanks for detailed feedback, please share your ideas about possible
improvements and additional features. For example, I am thinking about
extending the list of materials and adding a reference grid(s).

> 
> One of the models I uploaded (see my attached POV-ray render of your conversion)
> is a very high-triangle-count model, and very smooth when 3D-printed-- and it
> actually looked better on your webpage when I checked 'flat shading' there. As
> you can see here, the 'smooth triangles' of the converted mesh2 are causing the
> sharp edges to 'crinkle'...similar to what I saw when the model was 'smoothed'
> on your page.
> 
> My suggestion would be to allow a *choice* of downloading the mesh2 model as
> 'smooth triangles' or as just flat un-smoothed ones. My guess is that there are
> plenty of STL models available that don't really need such smoothing, because of
> their high triangle count.
> 
Agree with you and this is already works right "out of the box": just
select the "Flat shading" checkbox and _then_ download a model - you
will get exactly what you see :). The same approach works also for
"Vertex colors". I will write detailed help after some code polishing.

> My 2nd suggestion: Currently, your mesh2 downloads are named 'model' (as is the
> mesh2 itself.) They show up in my 'downloads' file...which, sadly, I don't
> immediately check or look at when I am busy with other things. So my second
> suggestion would be to *number* your converted files in some way, so that every
> file we convert has a unique number-- like model6374, similar to what
> Thingiverse does. The reason is that we could be uploading/downloading several
> models in quick succession...and new downloads could overwrite the previous ones
> if we are lazy :-O
Interesting idea, I will think about it. Implementation is trivial,
just need to be sure that this will be really convenient.

> 
> Thanks again for taking the time to create your site.
Always welcome !
Btw, you mentioned 3D printing - what model do you have and what
software do you prefer ? Mine is CREALITY3D ENDER-3 Pro / Simplify3d.

> 
> ----------------
> Over the last several days, I have been working on my own ascii-STL-to-mesh
> converter scheme, totally within POV-ray as SDL code (well, along with some
> 'manual/automated' editing of the STL file to get it into a form that POV-ray
> can #read.) But it's all accomplished within the program, no external editor
> required. Anyway, I finished it last night, and it works quite nicely. But THEN
> I saw that you had created your online converter! Which of course works better
> and faster than my DIY scheme. Mine only works with ascii files anyway.
> 
> I think I will still post it though, for those hardy souls who like doing things
> themselves. ;-)
No doubt - publish it !
Someone can use your code as an example for similar projects.

Wishing well.
-- 
YB

[Bald Eagle] Re: Online files converter [194 days 15 hours and 56 minutes ago]

Tue, 30 Sep 2025 13:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> My suggestion would be to allow a *choice* of downloading the mesh2 model as
> 'smooth triangles' or as just flat un-smoothed ones. My guess is that there are
> plenty of STL models available that don't really need such smoothing, because of
> their high triangle count.

All of the data is there, and the output can be tailored to the end use.
Why not have mesh2{} and the trivial{} mesh as well?

> My 2nd suggestion: Currently, your mesh2 downloads are named 'model' (as is the
> mesh2 itself.) They show up in my 'downloads' file...which, sadly, I don't
> immediately check or look at when I am busy with other things. So my second
> suggestion would be to *number* your converted files in some way, so that every
> file we convert has a unique number

I would suggest that a user-defined name be entered, and that way the filename
AND mesh2 object can just be given that name straightaway.
Also, [X] include inside_vector
Default behaviour might be to keep the "model" name, but make the filename some
date/time combo - that also makes it easier to find in a big directory of stuff.
"I think I downloaded that as the first file on Thursday...."

>...and new downloads could overwrite the previous ones
> if we are lazy :-O

My browsers usually append a (1), (2), .. (n) to the filename automatically.
Maybe you have similar in settings?

> Thanks again for taking the time to create your site.

Absolutely!  He does have plenty of skill and energy.

> I think I will still post it though, for those hardy souls who like doing things
> themselves. ;-)

Good work, Kenneth.  :)
Every project that gets posted is one that we can all learn from, and one that
doesn't get lost in the Sands of Time.

- BW

[Kenneth] Re: Online files converter [194 days 17 hours and 31 minutes ago]

Tue, 30 Sep 2025 12:10:00 GMT

yesbird wrote:
> Finally, after two sleepless nights I finished a web application that
> converts obj, fbx, glb, gltf, stl formats to mesh2:
> https://povlab.yesbird.online/all2pov
>

[Running Windows 10 and v3.8 beta 1; Firefox is my browser]

That is really a fabulous service, yesbird! I just used it to convert two
binary-file STL models (from Thingiverse) that I have been wanting to see in
POV-ray for a long time.

Your site works beautifully, and the upload/download speeds for me are VERY
fast. I am amazed at how quickly you wrote code to accomplish this task. Thank
you!

I know that you are busy with other things, but I have several small(?)
suggestions:

One of the models I uploaded (see my attached POV-ray render of your conversion)
is a very high-triangle-count model, and very smooth when 3D-printed-- and it
actually looked better on your webpage when I checked 'flat shading' there. As
you can see here, the 'smooth triangles' of the converted mesh2 are causing the
sharp edges to 'crinkle'...similar to what I saw when the model was 'smoothed'
on your page.

My suggestion would be to allow a *choice* of downloading the mesh2 model as
'smooth triangles' or as just flat un-smoothed ones. My guess is that there are
plenty of STL models available that don't really need such smoothing, because of
their high triangle count.

My 2nd suggestion: Currently, your mesh2 downloads are named 'model' (as is the
mesh2 itself.) They show up in my 'downloads' file...which, sadly, I don't
immediately check or look at when I am busy with other things. So my second
suggestion would be to *number* your converted files in some way, so that every
file we convert has a unique number-- like model6374, similar to what
Thingiverse does. The reason is that we could be uploading/downloading several
models in quick succession...and new downloads could overwrite the previous ones
if we are lazy :-O

Thanks again for taking the time to create your site.

----------------
Over the last several days, I have been working on my own ascii-STL-to-mesh
converter scheme, totally within POV-ray as SDL code (well, along with some
'manual/automated' editing of the STL file to get it into a form that POV-ray
can #read.) But it's all accomplished within the program, no external editor
required. Anyway, I finished it last night, and it works quite nicely. But THEN
I saw that you had created your online converter! Which of course works better
and faster than my DIY scheme. Mine only works with ascii files anyway.

I think I will still post it though, for those hardy souls who like doing things
themselves. ;-)

[yesbird] Re: Online files converter [194 days 18 hours and 6 minutes ago]

Tue, 30 Sep 2025 11:35:37 GMT

On 30/09/2025 12:04, Mr wrote:
> This looks awesome !!!
Thanks, to my pleasure ).

> 
> But I get " 504 Gateway Timeout " from behind my corporate proxy.(for all of
> your site by the way).
> 
Sad times we are living in ...

> So trying on my phone, I get a display smaller than my screen. but appearing
> functional.
> 
I didn't think about mobile platforms, working on design, so some
distortions are possible, but maybe this is better than nothing.)

At present the assumed resolution is HD 1920x1080, but I will try to
improve it.
--
YB

[yesbird] Re: Online files converter [194 days 18 hours and 29 minutes ago]

Tue, 30 Sep 2025 11:12:21 GMT

On 30/09/2025 12:07, Mr wrote:
> I think you should look at GIS packages (QGis/OpenSceneGraph...), and the way
> geometries are coupled with a text based projection file... recording
> coordinates, centering for treating and reapplying on exit. or leaving separate
> file from option?
> 

Thanks - this is an interesting idea, taking in account that I have
experience working with QGis and like it very much.

There is always a space for improvement :)
--
YB

[Mr] Re: Online files converter [194 days 20 hours and 31 minutes ago]

Tue, 30 Sep 2025 09:10:00 GMT

yesbird wrote:
> On 28/09/2025 15:42, Bald Eagle wrote:
> > You could also possibly have a labeled grid, and display the center of the
> > object in text.  Maybe have a checkbox "Center at origin".
> >
> > OK, maybe since a lot of objects are things that sit on a surface, have a second
> > checkbox that centers the object, and has its ymin set at 0.
> >
>
> This is the point for discussion: should converter change
> object's coordinates or just repack then into other format ?
> I guess, this is the editor's function.
>
> Maybe, it will be better just position the camera to look at object
> and set acceptable zoom ?
>
> In attachment: 'hand', loaded into C4D.
> --
> YB

I think you should look at GIS packages (QGis/OpenSceneGraph...), and the way
geometries are coupled with a text based projection file... recording
coordinates, centering for treating and reapplying on exit. or leaving separate
file from option?

[Mr] Re: Online files converter [194 days 20 hours and 36 minutes ago]

Tue, 30 Sep 2025 09:05:00 GMT

yesbird wrote:
> Finally, after two sleepless nights I finished a web application that
> converts obj, fbx, glb, gltf, stl formats to mesh2:
> https://povlab.yesbird.online/all2pov
>
> I tested it only on a limited number of files, so some issues
> (especially related to displaying a model) are possible, testing  now in
> progress. Please send any kind of feedback: bug reports, suggestions,
> requests to implement, etc.
> --
> YB

This looks awesome !!!

But I get " 504 Gateway Timeout " from behind my corporate proxy.(for all of
your site by the way).

So trying on my phone, I get a display smaller than my screen. but appearing
functional.

[yesbird] Re: Online files converter [195 days 9 hours and 6 minutes ago]

Mon, 29 Sep 2025 20:35:37 GMT

On 28/09/2025 01:27, yesbird wrote:
> Finally, after two sleepless nights I finished a web application that
> converts obj, fbx, glb, gltf, stl formats to mesh2:
> https://povlab.yesbird.online/all2pov
> ...

It is completed now: I implemented a progress bar and added two
additional metal materials for preview.
-- 
YB

[yesbird] Re: Online files converter [195 days 17 hours and 15 minutes ago]

Mon, 29 Sep 2025 12:25:59 GMT

On 29/09/2025 15:14, Bald Eagle wrote:
> 
> What I would greatly suggest is that you not just leave it as a converter, but
> add some small embellishments to make it a valuable learning tool.

Bill, thank you very much for this bundle of ideas, I will think about
them and follow your suggestions.

> So - that's always where my mind is going when we talk about any project.  "How
> do we attract people and bring them together to (re)build a thriving computer
> graphics community"
> 
Exactly, good luck with it. :)
-- 
YB

[Bald Eagle] Re: Online files converter [195 days 17 hours and 26 minutes ago]

Mon, 29 Sep 2025 12:15:00 GMT

yesbird wrote:

> Many thanks for this info, I will get back to splines after converter
> polishing.

Of course.
It's always nice to have a sort of head-start, with some keywords and even code
to get things moving quickly.

> Btw, would you suggest the best way to inform the community
> about its existence ?

What I would greatly suggest is that you not just leave it as a converter, but
add some small embellishments to make it a valuable learning tool.

It ought to be easy enough to make a small mesh and show how the normals are
calculated, how vector cross products allow the order of the vertices to
determine the direction of the normal, etc.
[X] Create an explanatory diagram as an .inc file

Then you can not only advertise it here on the forum, and elsewhere, but also
slip references to it in discussions on stackexchnge, stackoverflow, Wolfram,
and other places.  Make sure you have a didactic, academic graphic that will
attract computer science / graphics / gaming students to visit your app if they
come across it in a web search.  That way it has a lasting value completely
aside from JustAnotherFileConverter.
Make sure you put some prominent references to POV-Ray and the newsgroups in
your graphic. (I'd also suggest putting some standard POV-Ray header info in the
inc file, along with a reference to you & your web converter URL)

That way, if people find your project to be a useful learning tool in addition
to it being just a converter, they may be encouraged to try POV-Ray, and get
involved with many of the projects - including the ones you are working on, or
don't have time to work on.  And I have no problem with using 3js as the basis
for a new version of POV-Ray, so any CG tools developed in 3js are valuable as
well. (You know I draw my knowledge and inspirations from a wide range of
platforms and sources)

So - that's always where my mind is going when we talk about any project.  "How
do we attract people and bring them together to (re)build a thriving computer
graphics community"

- BW

[yesbird] Re: Online files converter [195 days 18 hours and 31 minutes ago]

Mon, 29 Sep 2025 11:10:18 GMT

On 29/09/2025 04:25, Bald Eagle wrote:
> 
> Yes, I am certain that such a thing would be useful.
> ...

Many thanks for this info, I will get back to splines after converter
polishing. Btw, would you suggest the best way to inform the community
about its existence ?
-- 
YB

[Bald Eagle] Re: Online files converter [196 days 4 hours and 11 minutes ago]

Mon, 29 Sep 2025 01:30:00 GMT

yesbird wrote:

> You are always welcome, now I am start thinking about spline
> editor for POV-Ray, based on this example:
> https://threejs.org/examples/webgl_geometry_spline_editor.html

Yes, I am certain that such a thing would be useful.

Ed Hynan wrote
https://web.mit.edu/povray_v3.7.0a/epspline.pdf
a while back,

and there was the PointWriter project

And someone had a spline workshop, IIRC.

Tor Olav Kristensen (TOK) has a lot of spline stuff on github

Jerome Grimbert (Le Forgeron) has his hgpov38 project that uses a wide variety
of splines

And I made a big list for jr of all the different spline types

So there's certainly a lot of things that could keep you busy  ;)

- BW

[yesbird] Re: Online files converter [196 days 5 hours and 4 minutes ago]

Mon, 29 Sep 2025 00:37:25 GMT

On 29/09/2025 03:00, Bald Eagle wrote:
> Looks good.
> Got the teapot when the webpage loaded.
> Took maybe 30 sec to convert the ghost.
> 
> (slick future feature would be to use a url, and convert from inside a zip.)

YES! I am glad that finally you win.

But 30 sec is toooo looong for such small model, I am getting result in
2-3 sec, but there is ocean between us :).

Possible solution: I can open github repository and you will be able to
install this service on more accessible server.

> Thank you, Sergei.

You are always welcome, now I am start thinking about spline
editor for POV-Ray, based on this example:
https://threejs.org/examples/webgl_geometry_spline_editor.html
-- 
YB

[Bald Eagle] Re: Online files converter [196 days 5 hours and 21 minutes ago]

Mon, 29 Sep 2025 00:20:00 GMT

yesbird wrote:

> Beg me pardon, but why not Chrome or Firefox ?

Thou hast no need for begging for anything, least of all a pardon.

I simply don't have those installed on any of my machines.

I do have "LibreWolf", but many sites don't like the signature of that.

- BW

[Bald Eagle] Re: Online files converter [196 days 5 hours and 36 minutes ago]

Mon, 29 Sep 2025 00:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I'll give it a whirl in Edge since I already have the Win11 spyvirus on my
> laptop.

Looks good.
Got the teapot when the webpage loaded.
Took maybe 30 sec to convert the ghost.

(slick future feature would be to use a url, and convert from inside a zip.)

mesh.inc autosaved to my downloads folder.
object is called "model"
Not centered at origin
No inside_vector defined

After finding my object with min_extent, translating and rotating
it seems to work fine.

:)

Thank you, Sergei.

- BW

[yesbird] Re: Online files converter [196 days 5 hours and 41 minutes ago]

Sun, 28 Sep 2025 23:59:50 GMT

On 29/09/2025 02:34, Bald Eagle wrote:
> 
> I'll give it a whirl in Edge since I already have the Win11 spyvirus on my
> laptop.

Beg me pardon, but why not Chrome or Firefox ?
-- 
YB

[Bald Eagle] Re: Online files converter [196 days 6 hours and 6 minutes ago]

Sun, 28 Sep 2025 23:35:00 GMT

yesbird wrote:

> Looks like WebGl1 is insufficient for Three.js and it wants WebGL2.
> Did you tried it with Opera ?

Looks to be the same thing.
Tried enabling a thing in Brave to allow WebGL2, but that didn't work.

I'll give it a whirl in Edge since I already have the Win11 spyvirus on my
laptop.

- BW

[yesbird] Re: Online files converter [196 days 6 hours and 16 minutes ago]

Sun, 28 Sep 2025 23:25:11 GMT

On 29/09/2025 01:02, Bald Eagle wrote:
> 
> I would say it depends on what the user wants.
> ...

I absolutely agree with all your statements, let's collect
user's opinions and then make decisions about further development.

The only question I have: how to inform the maximum number of 'povers'
about this service ?
-- 
YB

[yesbird] Re: Online files converter [196 days 6 hours and 59 minutes ago]

Sun, 28 Sep 2025 22:41:57 GMT

On 29/09/2025 00:55, Bald Eagle wrote:
> Brave supports WebGl1
> 
> Ã— This browser supports WebGL 2, but it is disabled or unavailable.
> 
> Sometimes this is the result of older video drivers being rejected by the
> browser. Try updating your video drivers if possible.
> 
> Also check out Get WebGL, or try installing the latest version of Chrome, or
> Firefox.
...
> Reason:  Failed to create a WebGL2 context.

Looks like WebGl1 is insufficient for Three.js and it wants WebGL2.
Did you tried it with Opera ?

"Don't give in without a fight" :).
-- 
YB

[Bald Eagle] Re: Online files converter [196 days 7 hours and 36 minutes ago]

Sun, 28 Sep 2025 22:05:00 GMT

yesbird wrote:

> This is the point for discussion: should converter change
> object's coordinates or just repack then into other format ?
> I guess, this is the editor's function.

I would say it depends on what the user wants.
Blindly converting from one format to another, the computer doesn't "know".

> Maybe, it will be better just position the camera to look at object
> and set acceptable zoom ?

I mean, that's fine for default behaviour, however I'd provide the option to
center in either of the two ways I suggested.

> In attachment: 'hand', loaded into C4D.

So here we have a "part" of what if likely a bigger object / assembly.
It would make sense that it is positioned in relation to the other parts, and so
changing that deletes that very carefully specified position.

Having a coffee mug 100 units in the air and WAY off center doesn't make a lot
of sense.  We'd want to fix that obvious problem so that it doesn;t have to be
accounted for every time we instantiate the mesh, so it would get centered, with
y=0.

For other meshes, where having the center of the object at the origin would make
more sense from a rendering / modeling standpoint, then that would also be a
valid option.

But only the human user can look at that and know for sure.

- BW

[Bald Eagle] Re: Online files converter [196 days 7 hours and 41 minutes ago]

Sun, 28 Sep 2025 22:00:00 GMT

yesbird wrote:

> Bill, first of all please check if your browser supports WebGL:
> https://webglreport.com/

Brave supports WebGl1

× This browser supports WebGL 2, but it is disabled or unavailable.

Sometimes this is the result of older video drivers being rejected by the
browser. Try updating your video drivers if possible.

Also check out Get WebGL, or try installing the latest version of Chrome, or
Firefox.


> Then select _console_ tab after pressing F12 and look for
> errors there.

three.module.js:29414 THREE.WebGLRenderer: A WebGL context could not be created.
Reason:  Could not create a WebGL context, VENDOR = 0x8086, DEVICE = 0x0412,
GL_VENDOR = Google Inc. (Intel), GL_RENDERER = ANGLE (Intel, Intel(R) HD
Graphics 4600 Direct3D9Ex vs_3_0 ps_3_0, igdumdim64.dll -10.18.14.5180),
GL_VERSION = 10.18.14.5180, Sandboxed = yes, Optimus = no, AMD switchable = no,
Reset notification strategy = 0x8252, ErrorMessage = BindToCurrentSequence
failed: .
onContextCreationError @ three.module.js:29414
three.module.js:29414 THREE.WebGLRenderer: A WebGL context could not be created.
Reason:  Failed to create a WebGL2 context.
onContextCreationError @ three.module.js:29414
three.module.js:29414 THREE.WebGLRenderer: A WebGL context could not be created.
Reason:  Could not create a WebGL context, VENDOR = 0x8086, DEVICE = 0x0412,
GL_VENDOR = Google Inc. (Intel), GL_RENDERER = ANGLE (Intel, Intel(R) HD
Graphics 4600 Direct3D9Ex vs_3_0 ps_3_0, igdumdim64.dll -10.18.14.5180),
GL_VERSION = 10.18.14.5180, Sandboxed = yes, Optimus = no, AMD switchable = no,
Reset notification strategy = 0x8252, ErrorMessage = BindToCurrentSequence
failed: .
onContextCreationError @ three.module.js:29414
three.module.js:29414 THREE.WebGLRenderer: A WebGL context could not be created.
Reason:  Failed to create a WebGL2 context.
onContextCreationError @ three.module.js:29414
three.module.js:28990 THREE.WebGLRenderer: Error creating WebGL context.
WebGLRenderer @ three.module.js:28990
three.module.js:28980 Uncaught Error: Error creating WebGL context.
    at new WebGLRenderer (three.module.js:28980:13)
    at init (main.js:50:14)
    at main.js:316:7
main.js:267 Uncaught TypeError: Cannot read properties of undefined (reading
'setSize')
    at onWindowResize (main.js:267:12)



> Many thanks for testing, wishing well :).

Many thanks for writing, and wishing you and everyone else the best in these
crazy times.

- BW

[yesbird] Re: Online files converter [196 days 11 hours and 14 minutes ago]

Sun, 28 Sep 2025 18:27:10 GMT

On 28/09/2025 15:42, Bald Eagle wrote:
> 
> You could also possibly have a labeled grid, and display the center of the
> object in text.  Maybe have a checkbox "Center at origin".
> 
> OK, maybe since a lot of objects are things that sit on a surface, have a second
> checkbox that centers the object, and has its ymin set at 0.
>

I have improved the default view on loading, now model sits at the
center and fits the screen perfectly.
-- 
YB

[yesbird] Re: Online files converter [196 days 14 hours and 10 minutes ago]

Sun, 28 Sep 2025 15:31:30 GMT

On 28/09/2025 18:13, jr wrote:
> great !!!  that'll allow me to put the coffee cup and ashtray on the now unused
> keyboard </grin>.

I mean lack of GUI.
-- 
YB

[jr] Re: Online files converter [196 days 14 hours and 26 minutes ago]

Sun, 28 Sep 2025 15:15:00 GMT

hi,

yesbird wrote:
> ...
> Pan/Zoom/Scale can be controlled only by the mouse -
> this is standard now ...

great !!!  that'll allow me to put the coffee cup and ashtray on the now unused
keyboard </grin>.


regards, jr.

[yesbird] Re: Online files converter [196 days 15 hours and 11 minutes ago]

Sun, 28 Sep 2025 14:30:47 GMT

On 28/09/2025 15:42, Bald Eagle wrote:
> You could also possibly have a labeled grid, and display the center of the
> object in text.  Maybe have a checkbox "Center at origin".
> 
> OK, maybe since a lot of objects are things that sit on a surface, have a second
> checkbox that centers the object, and has its ymin set at 0.
> 

This is the point for discussion: should converter change
object's coordinates or just repack then into other format ?
I guess, this is the editor's function.

Maybe, it will be better just position the camera to look at object
and set acceptable zoom ?

In attachment: 'hand', loaded into C4D.
-- 
YB

[yesbird] Re: Online files converter [196 days 16 hours and 11 minutes ago]

Sun, 28 Sep 2025 13:30:40 GMT

On 28/09/2025 15:42, Bald Eagle wrote:
> yesbird wrote:
>> Bill, could you please look at the browser's console
>> (usually F12) and send me content ?
> 
> Tried again just now - I see no grid or rotation, or controls for zooming or
> panning.
> 
> When I was very new povver, I would draw arrows from the origin to objects or
> light sources to help me find where things were when they were out of view.
> 
> You could also possibly have a labeled grid, and display the center of the
> object in text.  Maybe have a checkbox "Center at origin".
> 
> OK, maybe since a lot of objects are things that sit on a surface, have a second
> checkbox that centers the object, and has its ymin set at 0.
> 
> - BW
> 
> 
> 
> 

Bill, first of all please check if your browser supports WebGL:
https://webglreport.com/

Then select _console_ tab after pressing F12 and look for
errors there.

Axis will act as reference. I will think about centering after
collecting more information and samples.

Pan/Zoom/Scale can be controlled only by the mouse -
this is standard now and I don't want to implement complicated
environment.

Many thanks for testing, wishing well :).
-- 
YB

[Bald Eagle] Re: Online files converter [196 days 16 hours and 56 minutes ago]

Sun, 28 Sep 2025 12:45:00 GMT

yesbird wrote:
> Bill, could you please look at the browser's console
> (usually F12) and send me content ?

Tried again just now - I see no grid or rotation, or controls for zooming or
panning.

When I was very new povver, I would draw arrows from the origin to objects or
light sources to help me find where things were when they were out of view.

You could also possibly have a labeled grid, and display the center of the
object in text.  Maybe have a checkbox "Center at origin".

OK, maybe since a lot of objects are things that sit on a surface, have a second
checkbox that centers the object, and has its ymin set at 0.

- BW

[yesbird] Re: Online files converter [196 days 20 hours and 3 minutes ago]

Sun, 28 Sep 2025 09:38:02 GMT

On 28/09/2025 06:53, yesbird wrote:
> Rook was uploaded and conversion also successful (attached), but you
> do not see it because pivot point is shifted and object is too far from
> origin. Just play with zoom/pan/rotation or fix it's position.
> 
The same things with 'ghost' and 'hand' (attached).
I will think about automated objects positioning ...
-- 
YB

[yesbird] Re: Online files converter [196 days 20 hours and 7 minutes ago]

Sun, 28 Sep 2025 09:33:59 GMT

On 28/09/2025 06:53, yesbird wrote:
> Rook was uploaded and conversion also successful (attached), but you
> do not see it because pivot point is shifted and object is too far from
> origin. Just play with zoom/pan/rotation or fix it's position.
> 

The same things with "hand" and "ghost" (see attachments).
I will think about automated objects positioning ...
-- 
YB

[yesbird] Re: Online files converter [197 days 1 hour and 48 minutes ago]

Sun, 28 Sep 2025 03:53:06 GMT

On 28/09/2025 04:24, m@b wrote:
> Same problem using Firefox.
> 2 objs did not upload, I tried a skull and only saw the bottom jaw.

Rook was uploaded and conversion also successful (attached), but you
do not see it because pivot point is shifted and object is too far from
origin. Just play with zoom/pan/rotation or fix it's position.

-- 
YB

[yesbird] Re: Online files converter [197 days 2 hours and 22 minutes ago]

Sun, 28 Sep 2025 03:19:27 GMT

On 28/09/2025 04:24, m@b wrote:
> Same problem using Firefox.
> 2 objs did not upload, I tried a skull and only saw the bottom jaw.

Firefox works fine, but you have two meshes in one OBJ file
(see attachment), but the only one is converting.
Just merge them together and you will have a complete skull :).
-- 
YB

[yesbird] Re: Online files converter [197 days 2 hours and 32 minutes ago]

Sun, 28 Sep 2025 03:09:01 GMT

On 28/09/2025 06:01, yesbird wrote:
> Successfully uploaded skull (see attachment) from Chrome.

And conversion also works fine (attached).
-- 
YB

[yesbird] Re: Online files converter [197 days 2 hours and 40 minutes ago]

Sun, 28 Sep 2025 03:01:19 GMT

On 28/09/2025 03:58, Bald Eagle wrote:
> You are pretty damned impressive Sergei.  :)

Thanks, but let's debug it first ).

> I tried it with both Brave browser and Opera.
> I tried to upload a file, and nothing happened.
> Would it be difficult to implement an upload progress bar?

I see following files uploaded to server:
Rook.stl, The Ghost.obj.stl, MATTOSTROM_SKULL2.obj.

Successfully uploaded skull (see attachment) from Chrome.
Also did minor changes to satisfy Firefox (m@b, please try again,
clearing cache before), but unfortunately I have no Brave and Opera for
testing. Bill, could you please look at the browser's console
(usually F12) and send me content ?

-- 
YB

[m@b] Re: Online files converter [197 days 4 hours and 17 minutes ago]

Sun, 28 Sep 2025 01:24:06 GMT

On 28/09/2025 08:58, Bald Eagle wrote:
> yesbird wrote:
>> Finally, after two sleepless nights I finished a web application that
>> converts obj, fbx, glb, gltf, stl formats to mesh2:
>> https://povlab.yesbird.online/all2pov
> 
> You are pretty damned impressive Sergei.  :)
> 
>> I tested it only on a limited number of files, so some issues
>> (especially related to displaying a model) are possible, testing  now in
>> progress. Please send any kind of feedback: bug reports, suggestions,
>> requests to implement, etc.
> 
> I tried it with both Brave browser and Opera.
> I tried to upload a file, and nothing happened.
> Would it be difficult to implement an upload progress bar?
> 
> Tried clicking on the download button, and nothing happened, presumably because
> the file never got uploaded or processed.
> 
> - BW
> 


Same problem using Firefox.
2 objs did not upload, I tried a skull and only saw the bottom jaw.

m@

[Bald Eagle] Re: Online files converter [197 days 4 hours and 41 minutes ago]

Sun, 28 Sep 2025 01:00:00 GMT

yesbird wrote:
> Finally, after two sleepless nights I finished a web application that
> converts obj, fbx, glb, gltf, stl formats to mesh2:
> https://povlab.yesbird.online/all2pov

You are pretty damned impressive Sergei.  :)

> I tested it only on a limited number of files, so some issues
> (especially related to displaying a model) are possible, testing  now in
> progress. Please send any kind of feedback: bug reports, suggestions,
> requests to implement, etc.

I tried it with both Brave browser and Opera.
I tried to upload a file, and nothing happened.
Would it be difficult to implement an upload progress bar?

Tried clicking on the download button, and nothing happened, presumably because
the file never got uploaded or processed.

- BW

[yesbird] Online files converter [197 days 7 hours and 14 minutes ago]

Sat, 27 Sep 2025 22:27:42 GMT

Finally, after two sleepless nights I finished a web application that
converts obj, fbx, glb, gltf, stl formats to mesh2:
https://povlab.yesbird.online/all2pov

I tested it only on a limited number of files, so some issues
(especially related to displaying a model) are possible, testing  now in
progress. Please send any kind of feedback: bug reports, suggestions,
requests to implement, etc.
--
YB

[Ilya Razmanov] Re: img2mesh geometry improved [201 days 11 hours and 38 minutes ago]

Tue, 23 Sep 2025 18:03:16 GMT

On 23.09.2025 13:46, yesbird wrote:

> I guess this method will be demanded not only by POV-Ray community, may
> be I will manage myself to rewrite it on Javascript to extent Three.js
> library (asking your permission before :)
You are allowed to use it as long as you keep hailing the Toad all the 
time. Oh, and bring me all your money you silly humans.

Seriously, I don't see anything special regarding my algorithm, just 
some common sense, so surely use it at will if you find it useful.

In fact, there is a room for improvements: I use the fact that fold 
geometry is just a particular case of pyramid one, and I use it with 
"sharp" threshold-based "if" condition. Surely I may try some "smooth" 
solution, with folds gradually turning into pyramids, for example, 
linearly based on local contrast. The problem is, all this comes to "I 
like the way it looks" criterion in the end, and I still don't have 
precise mathematical definition for "look", not to mention "like".

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

[yesbird] Re: img2mesh geometry improved [201 days 18 hours and 55 minutes ago]

Tue, 23 Sep 2025 10:46:41 GMT

On 22/09/2025 12:39, Ilya Razmanov wrote:
> 
> So, the question is: does anybody really need this img2mesh and stuff?
> 
Congratulations, this is excellent work !
I guess this method will be demanded not only by POV-Ray community, may
be I will manage myself to rewrite it on Javascript to extent Three.js
library (asking your permission before :)).

-- 
YB

[Ilya Razmanov] img2mesh geometry improved [202 days 20 hours and 2 minutes ago]

Mon, 22 Sep 2025 09:39:42 GMT

Greeting,

while fiddling with some old ideas I unintentionally managed to improve 
some aspects of my img2mesh Python image to heightfield 3D mesh converter.

You can view the results at the top of img2mesh page, updates section:

https://dnyarri.github.io/img2mesh.html

and download either Python originals or compiled Win10 exe.

In view of recent discussion "I would like to ask the community: do
we really need it?"

I mean new version uses geometry switch based on source local contrast, 
corresponding threshold control is added to program GUI but, obviously, 
it doesn't give real-time preview of final rendering. In theory, I may 
add something like ruby mask preview (like one in Photoshop) for local 
contrast to GUI, but, considering my extremely poor programming skills 
and bad memory, it would be quite time consuming. Surely, I was able to 
make a preview for filtering (you may see it at the bottom of my
POVâ€‘Ray 
Thread: Linen and Stitch at

https://dnyarri.github.io/povthread.html#averager

so I can do this, but it wasn't easy.

So, the question is: does anybody really need this img2mesh and stuff?

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

[Mediat] Re: Domenator, last version [368 days 15 hours and 36 minutes ago]

Wed, 9 Apr 2025 14:05:00 GMT

Hi Thomas

Good to see you're still interested.

Feel free to complain

All the best

[Ilya Razmanov] Re: Canvas and cross-stitching simulation [370 days 11 hours and 46 minutes ago]

Mon, 7 Apr 2025 17:55:25 GMT

On 07.04.2025 18:44, yesbird wrote:
> Excellent work !
> 
> It's very close to what I did in my embroidery viewer:
> https://embview.yesbird.online/
> 
> but I used:
> https://wilcom.com/embroiderystudio
> 
> for converting designs from different machines formats like
> HUS, PHC, PES, DST, etc to PNG.

Don't tell me about formats, I'm not a programmer, I just an old 
amphibian with some ideas that may be implemented using a computer. My 
experience with programming is weird. My first program was written in 
Pascal 2.0 for PDP for rectification column calculations. And so on.

This program, for example, contain PPM/PGM I/O module in pure Python, 
written by me just because I needed something for previewing nested XYZ 
lists as images and I tried to avoid all this "rich Python ecosystem" 
with all its limitations and version conflicts. It took me quite some 
time to make it robust but now I know how to handle even binary formats. 
Well, I know how to handle even binary formats to some degree ;-) To a 
degree enough to avoid handling formats as long as possible :-)

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

[yesbird] Re: Canvas and cross-stitching simulation [370 days 13 hours and 56 minutes ago]

Mon, 7 Apr 2025 15:44:55 GMT

On 07/04/2025 16:07, Ilya Razmanov wrote:
> Greetings,
> 
> I'd like to inform humans and other species that POVThread finally got 
> user-friendly interface (see attached) and adaptive average filtering 
> included, so now it's sort of self-contained and supposed to run under 
> Python 3.10 and above right out of the zip.
> ...

Excellent work !

It's very close to what I did in my embroidery viewer:
https://embview.yesbird.online/

but I used:
https://wilcom.com/embroiderystudio

for converting designs from different machines formats like
HUS, PHC, PES, DST, etc to PNG.
-- 
YB

[Ilya Razmanov] Re: Canvas and cross-stitching simulation [370 days 16 hours and 34 minutes ago]

Mon, 7 Apr 2025 13:07:00 GMT

Greetings,

I'd like to inform humans and other species that POVThread finally got 
user-friendly interface (see attached) and adaptive average filtering 
included, so now it's sort of self-contained and supposed to run under 
Python 3.10 and above right out of the zip.

Previews remain, as always, here:

https://dnyarri.github.io/povthread.html

and the program itself:

https://github.com/Dnyarri/POVthread

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

[yesbird] Online CSG editor with POV-Ray support [394 days 6 hours and 6 minutes ago]

Fri, 14 Mar 2025 23:35:06 GMT

Hi, all !

Gems enchanted me completely and after finishing database of
designs: https://gemview.yesbird.online
I am switched to online gems CAD system and nowÂ stable working proof of
concept is ready:https://gemview.yesbird.online/cad/

Although now it only in alpha version, geometry for POV-ray scenes can
be produced by exporting data in POV mesh2 formats (OBJ format is also
supported). Editor uses the CSG concept and is very simple and
intuitiveÂ - just don't forgetÂ to click 'Confirm' to apply the
current
operation.

Concept inspiredÂ by the following predecessors:
https://www.gemcad.com/
https://gemcutstudio.com/

Advices, suggestions andÂ any kind of criticism are welcome !
--
YB

[Thomas de Groot] Re: Domenator, last version [395 days 21 hours and 20 minutes ago]

Thu, 13 Mar 2025 08:21:14 GMT

Op 11/03/2025 om 15:22 schreef Mediat:
> Hi Everybody,
> 
> Here is the latest version of Domenator with plenty of new features
> 
> You may need some dll (freeglut.dll and glew32.dll)
> 
> Feel free to complain for bugsabsence of manual or new features.
> 

Hi Philippe!
Good to see you are still evolving/improving Domenator (version 13!). 
For some time now I have been very remote from these n.g.'s and I am 
trying to get again some grip on the development and use of our 
favourite apps (despite the increasingly encroaching RL...).

I am certainly going to use this new Domenator in the coming weeks...

-- 
Thomas

[Bald Eagle] Re: Domenator, last version [397 days 14 hours and 46 minutes ago]

Tue, 11 Mar 2025 14:55:00 GMT

"Mediat" <med### [at] hotmailfr> wrote:
> A sample : (yes it is only one dome with some new features)

Very nice.
This would solve the problem that was brought up here:

https://news.povray.org/povray.general/thread/%3Cweb.5d75c2d16af53e9cecc0fada0%40news.povray.org%3E/?mtop=431108

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5e97c744fd34edcfb0b41570%40news.povray.org%3E/

- BE

[Mediat] Re: Domenator, last version [397 days 15 hours and 16 minutes ago]

Tue, 11 Mar 2025 14:25:00 GMT

A sample : (yes it is only one dome with some new features)

[Mediat] Re: Domenator, last version [397 days 15 hours and 16 minutes ago]

Tue, 11 Mar 2025 14:25:00 GMT

Hi Everybody,

Here is the latest version of Domenator with plenty of new features

You may need some dll (freeglut.dll and glew32.dll)

Feel free to complain for bugsabsence of manual or new features.

[Ilya Razmanov] img2mesh version 3 [417 days 10 hours and 15 minutes ago]

Wed, 19 Feb 2025 19:26:17 GMT

Good news everyone:

I substantially changed my Python heightfiled to triangle mesh 
converter, img2mesh. Logically, new mesh structure had to be first to 
come to my mind, so, not surprisingly, it took more than a year. 
Surprising is rendering quality improvement - I expected it to be small 
and, actually, tried new scheme just out of curiosity. However, it 
appeared to be quite noticeable.

As an example, I attach a small rendering with source image. Source is 
small text passed through some Gaussian Blur, and I deliberately made it 
small, with font having thin diagonals, to get as many ugly artifacts as 
possible. However, they appeared to look much less ugly than I expected. 
Surely, I see facets at that one-pixel lines, but expected them to turn 
into total mess.

Surely, with bigger original it looks pretty smooth.

So, after getting such a results with POV-Ray, I had no choice but spend 
some time to change OBJ, STL and DXF exports as well, and now released a 
new version, v. 3, of img2mesh.

Some previews and explanation:

https://dnyarri.github.io/img2mesh.html

Git repository:

https://github.com/Dnyarri/img2mesh

and release, beside sources, contain Win64 exe for lazy Windows users:

https://github.com/Dnyarri/img2mesh/releases/tag/3.14.19.10

So it goes.

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

[yesbird] Re: Layered textures added to POV Mosaic [522 days 8 hours and 37 minutes ago]

Wed, 6 Nov 2024 21:04:12 GMT

On 05/11/2024 13:32, Ilya Razmanov wrote:
> Hm. With minimal efforts irregular may be blobs...

Yes, blobs may work well for this case, but it's difficult to control
them to achieve expected results. May be will be better to look toward
splines, for example ? And start from classic Voronoi pattern ;).

> https://dnyarri.github.io/sporadic/OHO.html

Very impressive- I like this effect !
--
YB

[Ilya Razmanov] Re: Layered textures added to POV Mosaic [523 days 19 hours and 9 minutes ago]

Tue, 5 Nov 2024 10:32:40 GMT

On 02.11.2024 10:50, yesbird wrote:

> Didn't you think about irregular patterns

Hm. With minimal efforts irregular may be blobs... I must admit I have a 
couple of blob variations on this theme, not included into public repo - 
I tried them as possible voxels and, for a beginning, as an alternative 
to my img2mesh, but blobs appeared to be not exactly what I was looking 
for (although, I must admit, some variants gave funny special effects. I 
don't remember whether I sent this link here already:
https://dnyarri.github.io/sporadic/OHO.html
).

Giving blobs irregularity and using just the same things I did not like 
before for a new purpose may be interesting...

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

[yesbird] Re: Layered textures added to POV Mosaic [526 days 21 hours and 50 minutes ago]

Sat, 2 Nov 2024 07:51:04 GMT

On 01/11/2024 22:44, Ilya Razmanov wrote:
> Greetings,
> 
> this is to inform you that I overcame my unwillingness to make output of 
> my POV Mosaic programs

Looks very accurate and beautiful, mosaic is a favorite game of my
childhood. Didn't you think about irregular patterns,
like Antonio Gaudi did ? :)
--
YB

[Ilya Razmanov] Layered textures added to POV Mosaic [527 days 9 hours and 57 minutes ago]

Fri, 1 Nov 2024 19:44:21 GMT

Greetings,

this is to inform you that I overcame my unwillingness to make output of 
my POV Mosaic programs

https://dnyarri.github.io/povzaika.html

too complex, and replaced previous short texture with fully blown 
texture{}, thus giving an ability to add layered textures to each little 
thingie. Currently output includes placeholder with completely 
transparent overlay, which can be easily redefined somewhere in the 
beginning of the scene file ("easily" means that I tried to dilute it 
with comments so you may find it among tons of other stuff you can 
"easily" redefine).

Also, as I presume this would be final release (I tend to presume it 
every time), currently PyPNG is included into repository and 
downloadable, as a result, all programs will work upon just double 
clicking after downloading and unzipping, assuming you have standard 
Python installation.

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

[yesbird] Re: Canvas and cross-stitching simulation [554 days 17 hours and 13 minutes ago]

Sat, 5 Oct 2024 12:28:22 GMT

On 05/10/2024 08:43, Ilya Razmanov wrote:
> That's because it's POVRay rendering quality ;-)
YES !
> 
> But well, the company which paid for that was devoured by something bigger, and 
> this bigger decided to bury a lot of stuff rather than digest the devoured.

I have the same sad experience - 25 years ago.

> I'm trying to push as much work as possible to POVRay, since it's not 
> only uses text format even I can understand and make programs output to, 
> but also releases me from writing a lot of programming stuff myself ;-)
>
This is the reason I like it and continue using it while a lot of new
modern raytracers around, moreover it's free. :)

Back to embroidery - Wilcom has a non-free REST-service that converts
embroidery machine formats (DST, PES, HUS) to PNG.DST is the 
postÂ popular and well known:
https://edutechwiki.unige.ch/en/Embroidery_format_DST

Don't you see some niche here for your next project ? ;)
--
YB

[Ilya Razmanov] Re: Canvas and cross-stitching simulation [554 days 23 hours and 58 minutes ago]

Sat, 5 Oct 2024 05:43:02 GMT

On 04.10.2024 23:14, yesbird wrote:

> I have liked embroidery since my childhood, last year I started this
> project: https://embview.povlab.online (not POV-related).
> 
> It's based on https://oesd.com designs converted to PNGs by
> https://wilcom.com
> software.
> 
> Your rendering quality is really high, at least comparable with Wilcom.

That's because it's POVRay rendering quality ;-)

Actually all this have some long history; about 20 years ago I was 
creating prototype for cross stitching visualization, using some mini-C. 
At that time only bitmap pattern based solutions seemed to exist, I made 
something algorithmical, with antialiasing and moving light. But well, 
the company which paid for that was devoured by something bigger, and 
this bigger decided to bury a lot of stuff rather than digest the devoured.

But since about half a year ago I decided to take a look at that Python 
people seem to praise, I apparently reincarnated some old ideas, 
including POVRay export ones. And since computers became faster during 
that 20 years, I obviously decided to reassign as much work as possible 
to POVRay ;-)

Unfortunately I can't directly transfer my old shaders to POVRay, and, 
I'm afraid, my declined vision limits my capabilities to visually 
inspect real materials for subsequent POVRay implementations, but well, 
it seems that using functions for normals somewhat helps in 
transitioning old stuff based on better vision. I'll try to add some 
more realistic finishes and normals to all this. One of the great things 
is that I can access POVRay's Perlin noise, that's really helpful. So 
I'm trying to push as much work as possible to POVRay, since it's not 
only uses text format even I can understand and make programs output to, 
but also releases me from writing a lot of programming stuff myself ;-)

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

[yesbird] Re: Canvas and cross-stitching simulation [555 days 9 hours and 26 minutes ago]

Fri, 4 Oct 2024 20:15:07 GMT

On 04/10/2024 18:44, Ilya Razmanov wrote:
> 
> Hopefully you find it useful for making greeting cards or something ;-)
> 
Really good, great job !

I have liked embroidery since my childhood, last year I started this
project: https://embview.povlab.online (not POV-related).

It's based on https://oesd.com designs converted to PNGs by
https://wilcom.com
software.

Your rendering quality is really high, at least comparable with Wilcom.
--
YB

[Ilya Razmanov] Canvas and cross-stitching simulation [555 days 13 hours and 57 minutes ago]

Fri, 4 Oct 2024 15:44:19 GMT

Greetings,

I'm glad to inform you that some of my tiny Python programs, offspring 
of POVRay Mosaic (which apparently was updated), currently considered 
worth a release:

https://dnyarri.github.io/povthread.html

Currently it includes two programs, one for converting PNG image to 
colored canvas simulation, another one for simulating cross-stitch using 
POV objects (torii in these cases). Canvas and stitches may be deformed 
according to Perlin noise, giving some realism to resulting rendering.

Hopefully you find it useful for making greeting cards or something ;-)

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

[yesbird] Re: Lightweight DXF to SDL converter [595 days 21 hours and 30 minutes ago]

Sun, 25 Aug 2024 08:11:41 GMT

On 25/08/2024 09:36, Ilya Razmanov wrote:
> Oh, sorry, I just found it in ECS, it's right-hand. I'm using this 
> description you suggested, but, comparing to, say, OBJ, DXF is hardly 
> the most clean and logical format ;-)

Yes, this is an ancient and very confusing format. Many years ago, being
a student, I was using it to export city buildings coordinates from
AutoCad for ecology calculations. At those times there was not any
alternatives.
--
YB

[Ilya Razmanov] Re: Lightweight DXF to SDL converter [595 days 23 hours and 5 minutes ago]

Sun, 25 Aug 2024 06:36:03 GMT

On 25.08.2024 1:33, yesbird wrote:

> I am not sure that understand you well, but I was following this 
> document while writing the code:
> https://images.autodesk.com/adsk/files/autocad_2012_pdf_dxf-reference_enu.pdf

Oh, sorry, I just found it in ECS, it's right-hand. I'm using this 
description you suggested, but, comparing to, say, OBJ, DXF is hardly 
the most clean and logical format ;-)

Just wanted to add DXF export to my img2mesh. Considering stl and obj 
exports already added in previous version, this will fully cover all the 
non-POV formats I ever encountered.

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

[yesbird] Re: Lightweight DXF to SDL converter [596 days 7 hours and 8 minutes ago]

Sat, 24 Aug 2024 22:33:41 GMT

On 24/08/2024 14:59, Ilya Razmanov wrote:
> Speaking of DXF - I'm completely unable to find any official info on DXF 
> coordinate system handidness. It seems like you just ignore it. Do you 
> know some secret truth hidden from me, or simply exploit the symmetry of 
> jewels?

I am not sure that understand you well, but I was following this 
document while writing the code:
https://images.autodesk.com/adsk/files/autocad_2012_pdf_dxf-reference_enu.pdf

--
YB

[Ilya Razmanov] Re: Lightweight DXF to SDL converter [596 days 17 hours and 41 minutes ago]

Sat, 24 Aug 2024 11:59:49 GMT

On 12.05.2024 22:39, yesbird wrote:

> I've put it to repository for those, who will need it:
> https://github.com/syanenko/dxf2pov

Speaking of DXF - I'm completely unable to find any official info on DXF 
coordinate system handidness. It seems like you just ignore it. Do you 
know some secret truth hidden from me, or simply exploit the symmetry of 
jewels?

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

[Ilya Razmanov] 3/6 POVRay mosaic (was Re: POV Mosaic rewritten) [629 days 18 hours and 8 minutes ago]

Mon, 22 Jul 2024 11:33:29 GMT

Today I want to offer my full support and endorsement for... sorry, 
couldn't resist.

Last missing part was added to POVRay mosaic: the one for triangular 3/6 
pattern:

https://dnyarri.github.io/pov36zaika.html

IMHO it's the least promising part of the collection, but may be it's 
just because I personally can't imagine such a variability of patterns 
as it is possible with the others.

Speaking of the others, other programs in this pack got some 
improvements, and some more presets are added, including supposedly 
funny ones (example of new 44zaika preset "44_puzzle.inc" rendering 
attached).

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

[Ilya Razmanov] img2mesh mapping added (was Re: img2mesh PNG hei... [661 days 13 hours and 5 minutes ago]

Thu, 20 Jun 2024 16:36:46 GMT

Ok, I was lying when I promised to stop updating img2mesh PNG 
heightfield to 3D mesh conversion utility:

https://github.com/Dnyarri/img2mesh

I realized that, when doing something with heightfields "for fun", that 
is, not trying to convert some actual geometry data but, say, creating 
fake coins or medals, I often repeat one procedure: in Photoshop, apply 
"Curves" to image, save it, convert to mesh, render, say "I need extend 
gradations here and invert this small part" and repeat it again and 
again (including saying).

To reduce time for resaving and number of resaying I implemented 
"Curves" right in exported POVRay file - with img2pov (and, 
correspondingly, img2mesh when POV export option is used) version 
2.8.2.5 z-coordinate of mesh triangles, generated and saved according to 
source PNG pixel brightness, is fed to map function in POVRay when 
rendering. By default exported map is five points linear spline, 
corresponding to straight line describing "identical" transform, i.e. 
input=output. Map description is placed near the beginning of scene file 
and I guess its two-column layout makes it easy to understand - input is 
the first column, output is second column, third column contains unused 
zeroes.

Note, that map does not change actual z coords in mesh, it is applied 
when scene is rendered, so map is non-destructive and may be returned to 
"identical" 0/0 - 1/1 line anytime you want. Note that, as a result, map 
works only in POV file - with STL and OBJ export there is no map, since 
only POVRay allows easy internal recalculation of every facet according 
to user-defined function.

Have fun,

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

[yesbird] Re: POV Mosaic rewritten [669 days 16 hours and 38 minutes ago]

Wed, 12 Jun 2024 13:03:43 GMT

On 12/06/2024 12:20, Ilya Razmanov wrote:
> I would like to inform that POVRay mosaic collection of Python programs

Excellent !
I like the cylinders as basic form and different angles layout.
Looks like it's possible to implement fur this way.
--
YB

[Ilya Razmanov] POV Mosaic rewritten [669 days 20 hours and 21 minutes ago]

Wed, 12 Jun 2024 09:20:31 GMT

Greeting,

I would like to inform that POVRay mosaic collection of Python programs
https://github.com/Dnyarri/POVmosaic
was completely rewritten, hopefully providing more flexibility and 
simplicity for end users.

POVRay mosaic is a set of programs, which read every pixel of source 
image and convert it into a 3D object, colored after source pixel, 
together with neighbour objects, thus creating something like 3D-mosaic. 
Object properties (location, size, rotation) can be made dependent 
(mapped) on source pixel brightness.

Several old programs were converted to just two: 3zaika and 4zaika, 
packing objects into triangle and square grids correspondingly. Main 
idea of rewriting was compressing all variables, introduced into initial 
versions, into compact set of #define objects, vectors and stuff. For 
example, default output of 3zaika is a union of tightly packed spheres, 
but you can turn it into perfectly packed hexagonal prisms by changing 
"#declare thingie = thingie_1" to "#declare thingie = thingie_4" in the 
"Selecting variants" section of exported POV files. Similarly you can 
switch predefined finishes and transfer functions. Surely, you can write 
your own - easiest way is patching scene with preset.inc files (some 
examples are provided). Some rendering examples are provided at 
https://dnyarri.github.io/
in corresponding sections. Help file, describing options in presumably 
human-compatible form, is included.

Hopefully you'll find it funny enough to start boring your friends with 
mosaic pictures.

Suggestions on extending are quite welcome.

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

[yesbird] Re: Lightweight DXF to SDL converter [675 days 12 hours and 48 minutes ago]

Thu, 6 Jun 2024 16:53:38 GMT

On 06/06/2024 08:34, Ilya Razmanov wrote:
> On 05.06.2024 23:11, yesbird wrote:
> 
> If you wish, you may take a look at "develop" branch at
> https://github.com/Dnyarri/POVmosaic
> Well be merged to "main" as soon (or as long?) as I finish writing more 
> or less useful preview page for a site.

Yes, it looks promising, I like an idea in general and examples you
provided in particular. Using dices is a very good finding !

> But it will make your part of the whole pack bigger than mine, rising 
> questions who is actual author here :-)

Nevermind - you can use it as you want. If this question is really
important for you - just rename variables and change the logic a little
and you will have your own code :).

Good luck,
--
YB.

[Ilya Razmanov] Re: Lightweight DXF to SDL converter [676 days and 6 minutes ago]

Thu, 6 Jun 2024 05:34:59 GMT

On 05.06.2024 23:11, yesbird wrote:

> Really interesting ! I've seen your mosaic works and like an idea to
> play with orientation of elements.

If you wish, you may take a look at "develop" branch at
https://github.com/Dnyarri/POVmosaic
Well be merged to "main" as soon (or as long?) as I finish writing more 
or less useful preview page for a site.

> May be now it's a time to play with
> geometry and materials also ?

Can't resist - attached is an example of one of presets. Main idea of 
this general rewrite is condensing most of controls I put at the first 
time here and there into compact set of #define, supposedly easy to 
understand (yeah, help file is still a bit smaller than a program 
itself! great achievement for me!) and definitely easier to edit, 
including the possibility to just link some preset.inc (the one for 
attached image includes, beside dice thingie rotate instructions, dice 
CSG itself) written in some more or less standard form.

There are also some predefined finishes and normals (the latter may be 
modified on a per thingie basis to avoid getting perfect Empire clones).

Surely, predefined finishes are basic, but it may be changed.

I didn't try to use fully blown texture template since it will make 
things overly complicated, but one can change my simple Python programs 
any way he/she want.

>> Â Not going to copy your files ...
> Why not ? You are welcome :)

But it will make your part of the whole pack bigger than mine, rising 
questions who is actual author here :-)

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

[yesbird] Re: Lightweight DXF to SDL converter [676 days 9 hours and 30 minutes ago]

Wed, 5 Jun 2024 20:11:19 GMT

On 05/06/2024 08:38, Ilya Razmanov wrote:
> So far it seems like your gem shapes are rather plugguble into 
> it as mosaic elements

Really interesting ! I've seen your mosaic works and like an idea to
play with orientation of elements. May be now it's a time to play with
geometry and materials also ?

>  Not going to copy your files ...
Why not ? You are welcome :)

> It would be against my creed to leave good stuff unborrowed :-)
Thanks, I've note it ).
--
YB.

[Ilya Razmanov] Re: Lightweight DXF to SDL converter [677 days and 3 minutes ago]

Wed, 5 Jun 2024 05:38:04 GMT

On 12.05.2024 22:39, yesbird wrote:

> While working on Gems factory:
> https://github.com/syanenko/povgems
Hmm, I missed that one before. I'm just trying to turn my old POVMosaic 
into something reasonably structured (already compressed most of them in 
two programs, most of others will be cancelled) with human-editable POV 
output. So far it seems like your gem shapes are rather plugguble into 
it as mosaic elements. Not going to copy your files, but, assuming I 
will be strong enough with the Force to build a preview webpage for my 
stuff to replace the old messy one, I'll definitely add a link. It would 
be against my creed to leave good stuff unborrowed :-)

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

[yesbird] Re: Lightweight DXF to SDL converter [683 days 16 hours and 44 minutes ago]

Wed, 29 May 2024 12:57:14 GMT

On 28/05/2024 23:09, Paolo Gibellini wrote:
> A _brilliant_ work, indeed!

Hi, Paolo.

I'm glad that you found it useful.
Always welcome :)
--
YB

[Paolo Gibellini] Re: Lightweight DXF to SDL converter [684 days 9 hours and 32 minutes ago]

Tue, 28 May 2024 20:09:44 GMT

Il 12/05/2024 21:39, yesbird ha scritto:
> Hi, folks !
> 
> While working on Gems factory:
> https://github.com/syanenko/povgems
> and Gems viewer:
> https://gemview.povlab.online/demo.html
> 
> I was need a tool to convert geometry data (DXF), produced by:
> https://www.gemcad.com
> to SDL 'on the fly' under Ubuntu.
> 
> I've put it to repository for those, who will need it:
> https://github.com/syanenko/dxf2pov
> 
> Happy poving :)

A _brilliant_ work, indeed!
And - btw - Gems viewer site is well done.

Thank you,
    Paolo

[yesbird] Lightweight DXF to SDL converter [700 days 10 hours and 2 minutes ago]

Sun, 12 May 2024 19:39:44 GMT

Hi, folks !

While working on Gems factory:
https://github.com/syanenko/povgems
and Gems viewer:
https://gemview.povlab.online/demo.html

I was need a tool to convert geometry data (DXF), produced by:
https://www.gemcad.com
to SDL 'on the fly' under Ubuntu.

I've put it to repository for those, who will need it:
https://github.com/syanenko/dxf2pov

Happy poving :)
-- 
YB.

[yesbird] Lightweight converter from DXF to SDL [700 days 12 hours and 21 minutes ago]

Sun, 12 May 2024 17:19:59 GMT

Hi, folks !

While working on Gems viewer:
https://gemview.povlab.online/demo.html
I was need a tool to convert geometry data (DXF), produced by:
https://www.gemcad.com
to SDL 'on the fly' under Ubuntu.

I've put it to repository for those, who will need it:
https://github.com/syanenko/dxf2pov

Happy poving :)
--
YB.

[Ilya Razmanov] img2mesh PNG height field to POV mesh converter ... [723 days 18 hours and 55 minutes ago]

Fri, 19 Apr 2024 10:46:10 GMT

Greeting,

bothering you to inform about (hopefully) final version of img2pov 
converter of PNG heightfields into POVRay 3D-mesh. The program uses 
image tracing algorithm quite different from normal, creating four 
triangle pyramids per pixel, rather than two triangle fold per four 
pixels as most programs do. Program is written in Python and is 
available from:

https://github.com/Dnyarri/img2mesh

In supposedly final 2.8.1.0 version POVRay output is completely 
rewritten to remove all POVRay transforms, hopefully making things to be 
parsed faster. Textures and stuff reorganized and reformatted to improve 
readability.

Also Wavefront OBJ and streolithography STL outputs added. Attached is a 
screencap of Windows Explorer window, showing icon preview of output 
generated from 2x2 pixels checkerboard PNG image (no idea who decided to 
introduce such a previews for potentially huge files but in this case it 
allows me to easily show them side by side without complex presentation).

Internally, img2pov, img2obj and img2stl programs converted into 
self-calling functions, thus allowing both running them as standalone 
and importing into some other program. For Windows users it gives a 
benefit of having single img2mesh GUI with import of all three of the 
above programs into single compressed EXE file, thus reducing the size 
of this all-in-one converter (exe file is available for download from 
"Release" section.

Hopefully this appear of some use :-)

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

[yesbird] Re: df3 tools [726 days 23 hours and 43 minutes ago]

Tue, 16 Apr 2024 05:58:16 GMT

On 15/04/2024 18:34, jr wrote:
> completely forgot, there's also a simple, script-driven DF3 "tool", using Tcl
> (in case that "floats your boat").
> <https://wiki.povray.org/content/User:Jr>

Thanks for this remind, I've seen it, but Tcl is a mystery to me :).
--
YB

[And] Re: Wood program but still develop [727 days 2 hours and 11 minutes ago]

Tue, 16 Apr 2024 03:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
> > I see this idea describing...
> > "when annual ring pattern is not very clear"
>
> I just posted it to show that there are a lot of functions out there, and we can
> mix and match them to eventually get the final result that we're looking for.
>
> Whereas some base patterns may be well suited to modification and perturbation
> in certain ways, others may not be.
>
> So I think that at the present, in the absence of anything concrete, it's good
> to compile a list of options, and then see what the strengths and weaknesses of
> them are, and proceed from there.
>
> And at some future point, someone may find it useful for some thing that's - not
> wood.
>
> - BE

Well.

[jr] Re: df3 tools [727 days 14 hours and 6 minutes ago]

Mon, 15 Apr 2024 15:35:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:

> > > ... toolset ...

completely forgot, there's also a simple, script-driven DF3 "tool", using Tcl
(in case that "floats your boat").
<https://wiki.povray.org/content/User:Jr>

> > as I've received this post as an email too, I'll reply to that, in the coming
> > days.  cheers.
> Looking forward for it,
> all the best.

cheers.  see inbox.

regards, jr.

[yesbird] Re: POV-Ray online rendering [728 days 8 hours ago]

Sun, 14 Apr 2024 21:41:09 GMT

Hi, Bill !
On 14/04/2024 02:58, Bald Eagle wrote:> Welcome back - I was wondering 
where you were off to...
I took some kind of vacation to have a rest from coding. After that I've
decided to switch from C++ to JS (after more then 25 years of C++).
Sometimes we need a total reset :)

Now I'm study WebGL/WebXR with my old/good/discontinued 'Oculus Go'.
This leads me to HgPovray as it has stereo camera can produce excellent
content for my XR gallery - I will post a link to it coming days, after
some final cleanup.

> .... and I see that you were busy making some serious toys for everyone to play
> with!  :)
Exactly, this is a tool I'm using for fast server-side rendering content
of a gallery, mentioned above. I was inspired by 'shadertoy', 'codepen',
'glitch'and other such online coding tools. Will be glad if it will help
to someone else.

> 
> Thank you, and Welcome Back.
Thanks, Bill, you are very friendly as usual, I am very glad to see/read
you again. Any ideas, suggestions, questions bug reports, etc. about
this project are welcome :).
--
YB

[yesbird] Re: df3 tools [728 days 8 hours and 40 minutes ago]

Sun, 14 Apr 2024 21:01:00 GMT

Hi, jr.
On 14/04/2024 23:00, jr wrote:
> it is a strange world we live in :-).  yesterday, early afternoon, true story, I
> started to think about a successor to the 'df3 tools' (incl taking notes), the
> first time in months!  (you must have been thinking very loudly </grin>)

You are right, I'm very serious about this project and the level of
concentration is high :).

> only had a very brief look at the povlab.online, cool idea.

Thanks, the sources of inspiration was 'stackblitz', 'codepen', 'glitch'
- tools for online JS coding.

> 
> as I've received this post as an email too, I'll reply to that, in the coming
> days.  cheers.
Looking forward for it,
all the best.
--
YB

[jr] Re: df3 tools [728 days 9 hours and 36 minutes ago]

Sun, 14 Apr 2024 20:05:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> On 10/07/2018 00:55, jr wrote:
> > announcing version 0.4.0 of the 'df3 tools'for working with DF3 files,
> Thank you very much for sharing this great toolset and library, I have
> built them successfully and now plan to use in my new volume
> visualization project. The goal is to create an online visualization
> tool of medical data in DICOM format, common voxelized data in OpenVDB
> format, and show results in WebXR as stereopair.

it is a strange world we live in :-).  yesterday, early afternoon, true story, I
started to think about a successor to the 'df3 tools' (incl taking notes), the
first time in months!  (you must have been thinking very loudly </grin>)

only had a very brief look at the povlab.online, cool idea.

as I've received this post as an email too, I'll reply to that, in the coming
days.  cheers.

regards, jr.

[Ilya Razmanov] Height field to mesh - POV, OBJ, STL support [728 days 9 hours and 58 minutes ago]

Sun, 14 Apr 2024 19:43:37 GMT

During major update of img2mesh utility for conversion of PNG 
heightfield into 3D mesh in an unusual way (and often better), complete 
rewriting of POVRay export code was made, removing all POVRay transforms 
(and apparently some artifacts) and supposedly making it render a tiny 
bit faster.

Beside that, Wavefront OBJ and stereolithography STL format output 
added. All Python sources available at:

https://github.com/Dnyarri/img2mesh

For Windows users, standalone Win64 exe compiled:

https://github.com/Dnyarri/img2mesh/releases/latest

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

[yesbird] Re: df3 tools [728 days 17 hours and 3 minutes ago]

Sun, 14 Apr 2024 12:38:18 GMT

On 10/07/2018 00:55, jr wrote:
> hi,
> 
> announcing version 0.4.0 of the 'df3 tools'for working with DF3 files,
> consisting of a C language library, a "Swiss army knife" type utility, and a
> database virtual table extension.
--

Hi, jr !
Thank you very much for sharing this great toolset and library, I have
built them successfully and now plan to use in my new volume
visualization project. The goal is to create an online visualization
tool of medical data in DICOM format, common voxelized data in OpenVDB
format, and show results in WebXR as stereopair.

The server-side rendering is doing by HgPovray38 - there is a pilot
version of this system that can be used as a sketchbook for experiments:
https://povlab.online/?scene=vol_3_slice.pov

As for WebXR, I already have an online gallery of stereo images rendered
with HgPovray that can be viewed in any VR headset. I will share the
link to it in a few days with more details in a separate post after some
cleanup.

The most important part of the project now is importing data from DICOM
and OpenVDB.
For DICOM I am looking at https://dicom.offis.de/dcmtk.php.en.
OpenVDB have an universal tool that, I believe, can be extended to
export df3 without serious effort:
https://github.com/AcademySoftwareFoundation/openvdb/tree/master/openvdb_cmd/vdb_tool

If you are still interested in df3 volumes, I will be glad to hear any
suggestions, thoughts, criticisms from you. And if you would like to
join this project somehow - you are welcome !
--
YB

[yesbird] Re: df3 tools [728 days 17 hours and 5 minutes ago]

Sun, 14 Apr 2024 12:36:01 GMT

On 10/07/2018 00:55, jr wrote:
> hi,
> 
> announcing version 0.4.0 of the 'df3 tools'for working with DF3 files,
> consisting of a C language library, a "Swiss army knife" type utility, and a
> database virtual table extension.
--
Hi, jr !
Thank you very much for sharing this great toolset and library, I have
built them successfully and now plan to use in my new volume
visualization project. The goal is to create an online visualization
tool of medical data in DICOM format, common voxelized data in OpenVDB
format, and show results in WebXR as stereopair.

The server-side rendering is doing by HgPovray38 - there is a pilot
version of this system that can be used as a sketchbook for experiments:
https://povlab.online/?scene=vol_3_slice.pov

As for WebXR, I already have an online gallery of stereo images rendered
with HgPovray that can be viewed in any VR headset. I will share the
link to it in a few days with more details in a separate post after some
cleanup.

The most important part of the project now is importing data from DICOM
and OpenVDB.
For DICOM I am looking at https://dicom.offis.de/dcmtk.php.en.
OpenVDB have an universal tool that, I believe, can be extended to
export df3 without serious effort: 
https://dirsig.cis.rit.edu/docs/new/vdb_tool.html

If you are still interested in df3 volumes, I will be glad to hear any
suggestions, thoughts, criticisms from you. And if you would like to
join this project somehow - you are welcome !
--
YB

[yesbird] Re: df3 tools [728 days 17 hours and 10 minutes ago]

Sun, 14 Apr 2024 12:31:05 GMT

On 10/07/2018 00:55, jr wrote:
> hi,
> 
> announcing version 0.4.0 of the 'df3 tools'for working with DF3 files,
> consisting of a C language library, a "Swiss army knife" type utility, and a
> database virtual table extension.
--

Hi, jr !
Thank you very much for sharing this great toolset and library, I have
built them successfully and now plan to use in my new volume
visualization project. The goal is to create an online visualization
tool of medical data in DICOM format, common voxelized data in OpenVSD
format, and show results in WebXR as stereopair.

The server-side rendering is doing by HgPovray38 - there is a pilot
version of this system that can be used as a sketchbook for experiments:
https://povlab.online/?scene=vol_3_slice.pov

As for WebXR, I already have an online gallery of stereo images rendered
with HgPovray that can be viewed in any VR headset. I will share the
link to it in a few days with more details in a separate post after some
cleanup.

The most important part of the project now is importing data from DICOM 
and OpenVSD.
For DICOM I am looking at https://dicom.offis.de/dcmtk.php.en.
OpenVSD, have an universal tool that, I believe, can be extended to
export df3 without serious effort:
https://github.com/AcademySoftwareFoundation/openvdb/tree/master/openvdb_cmd/vdb_tool

If you are still interested in df3 volumes, I will be glad to hear any
suggestions, thoughts, criticisms from you. And if you would like to
join this project somehow - you are welcome !
--
YB

[yesbird] Re: df3 tools [728 days 17 hours and 16 minutes ago]

Sun, 14 Apr 2024 12:25:32 GMT

On 10/07/2018 00:55, jr wrote:
> hi,
> 
> announcing version 0.4.0 of the 'df3 tools'for working with DF3 files,
> consisting of a C language library, a "Swiss army knife" type utility, and a
> database virtual table extension.
--

Hi, jr !
Thank you very much for sharing this great toolset and library, I have
built them successfully and now plan to use in my new volume
visualization project. The goal is to create an online visualization
tool of medical data in DICOM format, common voxelized data in OpenVSD
format, and show results in WebXR as stereopair.

The server-side rendering is doing by HgPovray38 - there is a pilot
version of this system that can be used as a sketchbook for experiments:
https://povlab.online/?scene=vol_3_slice.pov

As for WebXR, I already have an online gallery of stereo images rendered
with HgPovray that can be viewed in any VR headset. I will share the
link to it in a few days with more details in a separate post after some
cleanup.

The most important part of the project now is importing data from DICOM 
and OpenVSD.
For DICOM I am looking at https://dicom.offis.de/dcmtk.php.en.
OpenVSD, have an universal tool that, I believe, can be extended to
export df3 without serious effort: 
https://dirsig.cis.rit.edu/docs/new/vdb_tool.html

If you are still interested in df3 volumes, I will be glad to hear any
suggestions, thoughts, criticisms from you. And if you would like to
join this project somehow - you are welcome !
--
YB

[yesbird] Re: df3 tools [728 days 17 hours and 21 minutes ago]

Sun, 14 Apr 2024 12:20:25 GMT

On 10/07/2018 00:55, jr wrote:
> hi,
> 
> announcing version 0.4.0 of the 'df3 tools'for working with DF3 files,
> consisting of a C language library, a "Swiss army knife" type utility, and a
> database virtual table extension.

Hi, jr !
Thank you very much for sharing this great toolset and library, I have 
built them successfully and now plan to use in my new volume 
visualization project. The goal is to create an online visualization 
tool of medical data in DICOM format, common voxelized data in OpenVSD 
format, and show results in WebXR as stereopair.

The server-side rendering is doing by HgPovray38 - there is a pilot 
version of this system that can be used as a sketchbook for experiments: 
https://povlab.online/?scene=vol_3_slice.pov

As for WebXR, I already have an online gallery of stereo images rendered 
with HgPovray that can be viewed in any VR headset. I will share the 
link to it in a few days with more details in a separate post after some 
cleanup.

The most important part of the project now is importing data from DICOM 
and OpenVSD.
For DICOM I am looking at https://dicom.offis.de/dcmtk.php.en.
OpenVSD, have an universal tool that, I believe, can be extended to 
export df3 without serious effort: 
https://dirsig.cis.rit.edu/docs/new/vdb_tool.html

If you are still interested in df3 volumes, I will be glad to hear any 
suggestions, thoughts, criticisms from you. And if you would like to 
join this project somehow - you are welcome !
--
YB

[Bald Eagle] Re: POV-Ray online rendering [729 days 5 hours and 41 minutes ago]

Sun, 14 Apr 2024 00:00:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi, guys !
>
> After a long period of absence I'm getting back

Hi Sergei.
Welcome back - I was wondering where you were off to...
> and would like to share
> with you a tool for online rendering of POV-Ray scenes:
> https://povlab.online.

.... and I see that you were busy making some serious toys for everyone to play
with!  :)

And you're using HgPovRay38!   :O    Very cool!

I look forward to seeing what it can do.

Thank you, and Welcome Back.

- BE

[yesbird] POV-Ray online rendering [729 days 15 hours and 53 minutes ago]

Sat, 13 Apr 2024 13:48:03 GMT

Hi, guys !

After a long period of absence I'm getting back and would like to share
with you a tool for online rendering of POV-Ray scenes:
https://povlab.online.

I am using it for fast sketches to try some ideas that need more or less
serious computing power. Just select the desired scene from the bottom
panel, edit it as you like or paste your own, click the [Upload] button
in top right corner or press [Ctrl-S]. Behind the scene is HgPovray38
running on 10 cores of Intel(R) Xeon(R) CPU E5-2690 v2 3.00GHz.

Please be aware that this is only a beta version and any criticism,
suggestions, bug reports, or questions are welcome.

Code is here: https://github.com/syanenko/povlab.online
Happy rendering !

[Bald Eagle] Re: Wood program but still develop [731 days 18 hours and 41 minutes ago]

Thu, 11 Apr 2024 11:00:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

> I see this idea describing...
> "when annual ring pattern is not very clear"

I just posted it to show that there are a lot of functions out there, and we can
mix and match them to eventually get the final result that we're looking for.

Whereas some base patterns may be well suited to modification and perturbation
in certain ways, others may not be.

So I think that at the present, in the absence of anything concrete, it's good
to compile a list of options, and then see what the strengths and weaknesses of
them are, and proceed from there.

And at some future point, someone may find it useful for some thing that's - not
wood.

- BE

[And] Re: Wood program but still develop [732 days 23 hours and 26 minutes ago]

Wed, 10 Apr 2024 06:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Here's a dispersion pattern I found that seems to also make a good wood ring
> pattern.
>
> https://en.wikipedia.org/wiki/Dispersion_(water_waves)#Dispersion_relation
> https://www.desmos.com/calculator/dzrqmexxik
>
> #declare T_wave = 0.5; // -10 to 10 in example
> #declare FWave1 = function {sum (k_wave, 0.3, 3, mod ( (sqrt(x*x+y*y) - sqrt
> (9.81*k_wave*3)*T_wave)*k_wave*3, 2*pi) <= 1)}
> #declare FWave2 = function {sum (k_wave, 0.3, 3, abs ( (sqrt(x*x+y*y) - sqrt
> (9.81*k_wave*3)*T_wave)*k_wave*3) <= 0.3)}
> #declare Formula201 = function {(FWave1 (x, y, z) + FWave2 (x, y, z))/2}
>
> plane {z, 0 pigment {function {Formula201 (x,y,z)} } }
>
> Add 2 different color maps for light and dark wood, and it should look a lot
> better.


I see this idea describing...
"when annual ring pattern is not very clear"

[Ilya Razmanov] Print on canvas and cross-stitch added (was Re: ... [770 days 21 hours ago]

Sun, 3 Mar 2024 08:41:24 GMT

Greetings,

while trying to understand POVRay functions and turn them into 
procedural textures takes time, I decided to release my Python programs 
for creating POV scenes simulating textile and cross stitches in their 
current state, functions to be implemented later. So they are available 
for download at

https://github.com/Dnyarri/POVmosaic

in "tori" subfolder.

Also, I decided to reduce POVRay newsgroups server load, and create sort 
of preview site at

https://dnyarri.github.io/

There you can see some preview renderings at default settings. Most of 
projects described there are POVRay related.

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

[Bald Eagle] Re: Wood program but still develop [788 days 7 hours and 36 minutes ago]

Wed, 14 Feb 2024 22:05:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> I think I should learn Javafx first to rewrite it. My knowledge of design
> program is not enough.

Here's a dispersion pattern I found that seems to also make a good wood ring
pattern.

https://en.wikipedia.org/wiki/Dispersion_(water_waves)#Dispersion_relation
https://www.desmos.com/calculator/dzrqmexxik

#declare T_wave = 0.5; // -10 to 10 in example
#declare FWave1 = function {sum (k_wave, 0.3, 3, mod ( (sqrt(x*x+y*y) - sqrt
(9.81*k_wave*3)*T_wave)*k_wave*3, 2*pi) <= 1)}
#declare FWave2 = function {sum (k_wave, 0.3, 3, abs ( (sqrt(x*x+y*y) - sqrt
(9.81*k_wave*3)*T_wave)*k_wave*3) <= 0.3)}
#declare Formula201 = function {(FWave1 (x, y, z) + FWave2 (x, y, z))/2}

plane {z, 0 pigment {function {Formula201 (x,y,z)} } }

Add 2 different color maps for light and dark wood, and it should look a lot
better.

[Paolo Gibellini] Re: Converting image pixels into POV-Ray *anythi... [792 days 8 hours and 56 minutes ago]

Sat, 10 Feb 2024 20:45:39 GMT

28/01/2024 22:45, Ilya Razmanov wrote:
> If you take a look at these programs output, you'll see "thingie" 
> declared. That's the basic object, mosaic element. Later it gets color 
> and finish added, is scaled, rotated and moved where necessary, but the 
> same object is used for all mosaic. Therefore, you may replace it with 
> another object once, and it will be replaced throughout the whole scene 
> (just take care about it's size. For spheres and boxes it's 1*1*1, for 
> others described in the file), using the same symmetry as original. 
> About the only thing I don't recommend - using too complex objects. 
> Surely, you can edit POV file produced by my program to add .inc with 
> very complex object, and it will work (I've tried with spline 
> figurines), but very slowly.
> 
> Ilyich the Toad

At the moment is difficult for me to spare some time to code, but I will 
surely get a look.
A nice work!

Paolo

[Ilya Razmanov] Cross-stitch and print on canvas (RFC, sort of) [793 days 16 hours and 1 minute ago]

Fri, 9 Feb 2024 13:40:26 GMT

Greetings hunams,

I'm sort of in hopes of some feedback. As some may have noticed, I keep 
exploring idea of turning 2D image pixels into POVRay 3D objects and 
seeing what happens, and keep trying to use Python for that.

Attached are two small programs and one combined preview. One program 
turns image into something like print on canvas, while other turns image 
int cross-stitch.

The main problem is I'm not satisfied with normal. I did simulation os 
textile long ago and have some algorithmic normals witten in mini-C, 
but, unfortunately, I don't see the way to reproduce in with POVRay. SO 
far, I used spiral, but it's far from ideal.

Also I'm not quite satisfied with finish, but that's mostly problem of 
my not so perfect vision.

I have a high hope that someone take a look at it, dare to start it 
(hopefully Python is installed already) and probably give some feedback.

Note that these programs are not released yet, only sent here since I 
hope for feedback allowing me to improve it.

Ilyich the Toad
https://github.com/Dnyarri/  -  image to POV utils

[Ilya Razmanov] Blobs (UPD: Converting image pixels into POV-Ray... [796 days 23 hours and 2 minutes ago]

Tue, 6 Feb 2024 06:39:36 GMT

Greeting,

one more subproject at
https://github.com/Dnyarri/POVmosaic
released, namely blob one. Corresponding programs convert input image 
into sphere blob. Mostly based on Sphere Mosaic project but, since blob 
components have different argument number than spheres, replacing 
spheres with blob spheres cannot be done easily with text editor and 
required separate program.

Example image attached, all the Python stuff from the project available 
at Release page
https://github.com/Dnyarri/POVmosaic/releases/tag/2024.02.06
attached as well.

Now it's time to deal with more complex objects... (beware)

Ilyich the Toad

[Ilya Razmanov] Superellipsoids (was: Converting image pixels in... [800 days 15 hours and 13 minutes ago]

Fri, 2 Feb 2024 14:28:42 GMT

Greeting,

weeked season of grand openings at
https://github.com/Dnyarri/POVmosaic
meaning first of subfolders is opened to public, namely superellipsoid one.

Currently contain just one program to convert image into a mosaic of 
superellipsoids with random parameters. Effect is rather pop than 
artistic, but probably useful to make people laugh. Any suggestions on 
mapping superellipsoids to something else rather than random are welcome.

Ilyich the Toad
https://github.com/Dnyarri

[Ilya Razmanov] Re: Converting image pixels into POV-Ray *anythi... [805 days 7 hours and 56 minutes ago]

Sun, 28 Jan 2024 21:45:05 GMT

On 28.01.2024 21:14, Paolo Gibellini wrote:
> 
> This is a good shot, Ilya!
> Now, you can use each kind of shape, like in the old GIMP filter.

If you take a look at these programs output, you'll see "thingie" 
declared. That's the basic object, mosaic element. Later it gets color 
and finish added, is scaled, rotated and moved where necessary, but the 
same object is used for all mosaic. Therefore, you may replace it with 
another object once, and it will be replaced throughout the whole scene 
(just take care about it's size. For spheres and boxes it's 1*1*1, for 
others described in the file), using the same symmetry as original. 
About the only thing I don't recommend - using too complex objects. 
Surely, you can edit POV file produced by my program to add .inc with 
very complex object, and it will work (I've tried with spline 
figurines), but very slowly.

Ilyich the Toad

[Paolo Gibellini] Re: Converting image pixels into POV-Ray *anythi... [805 days 11 hours and 27 minutes ago]

Sun, 28 Jan 2024 18:14:21 GMT

Il 28/01/2024 18:11, Ilya Razmanov ha scritto:
> Well, it should have been happen someday: to the collection of Python 
> programs for conversion of bitmap into POVRay solid objects mosaic two 
> more programs (p3zaika.py and p6zaika.py) were added, converting bitmap 
> into a pack of triangle prisms or hexagonal prisms, correspondingly 
> (sample output of p6zaika attached).
> 
> All programs reside at
> https://github.com/Dnyarri/POVmosaic
> and may be used, modified and tortured for free.
> 
> So, currently spheres, cubes, and two sorts of prisms are included as 
> mosaic primitives, and all regular plane partitions (3/6, 4/4 and 6/3) 
> covered. Considering the fact that POV output of these is as flexible as 
> I could imagine, so you may edit objects properties or even replace 
> objects globally, there is a vast opportunity to produce mosaic-looking 
> posters, greetings cards, ads, and, all in all, molest humans 
> graphically. Enjoy.
> 
> Meanwhile, while POV primitives seem to be exhaused (more or less), I 
> may probably continue with something more complex. Beware.
> 
> Ilyich the Toad
> https://github.com/Dnyarri

This is a good shot, Ilya!
Now, you can use each kind of shape, like in the old GIMP filter.
Interesting work.

Paolo

[Ilya Razmanov] Converting image pixels into POV-Ray anything ... [805 days 12 hours and 30 minutes ago]

Sun, 28 Jan 2024 17:11:32 GMT

Well, it should have been happen someday: to the collection of Python 
programs for conversion of bitmap into POVRay solid objects mosaic two 
more programs (p3zaika.py and p6zaika.py) were added, converting bitmap 
into a pack of triangle prisms or hexagonal prisms, correspondingly 
(sample output of p6zaika attached).

All programs reside at
https://github.com/Dnyarri/POVmosaic
and may be used, modified and tortured for free.

So, currently spheres, cubes, and two sorts of prisms are included as 
mosaic primitives, and all regular plane partitions (3/6, 4/4 and 6/3) 
covered. Considering the fact that POV output of these is as flexible as 
I could imagine, so you may edit objects properties or even replace 
objects globally, there is a vast opportunity to produce mosaic-looking 
posters, greetings cards, ads, and, all in all, molest humans 
graphically. Enjoy.

Meanwhile, while POV primitives seem to be exhaused (more or less), I 
may probably continue with something more complex. Beware.

Ilyich the Toad
https://github.com/Dnyarri

[Ilya Razmanov] Re: Upd: not only spheres [819 days 14 hours and 13 minutes ago]

Sun, 14 Jan 2024 15:28:10 GMT

On 14.01.2024 10:11, Thomas de Groot wrote:
> I think it is neat and I like it. Maybe this is also thought of here, 
> but what if the cube rotations were increasingly random with 
> increasingly darker colours?
Well, programs are small and key part is mostly concentrated in on 
string, so, if you have Python (I had it because daughter installed it 
for some other purposes, so, to get the Python, you should get a 
daughter as an installation manager), you can rotate, resize, whatever 
these cubes as you wish. Besides, they are not just cubes - they are 
declared as "thingie" in the beginning of POV file, so you can change 
them from "box" to something else. The only reason I don't do every 
possible thing inside program is that it would actually require some 
fast preview to make sence of such a flexible editing, and I don't see 
the way to have a preview so far. Rumors are there's a OpenGL for 
Python, but I have no experience with it, maybe it's not good enough for 
my purpose.

But well, so far you can edit all this with text editor and hopefully do 
something that may be considered "art".

Ilya

[Thomas de Groot] Re: Upd: not only spheres [819 days 22 hours and 30 minutes ago]

Sun, 14 Jan 2024 07:11:11 GMT

Op 13/01/2024 om 09:44 schreef Ilya Razmanov:
> Sorry, wrong picture. Now attached it result of "b4zaikaR" with default 
> setting. Source image is also attached. I hope it sort of shows the idea 
> I had in mind when starting it.
> 

I think it is neat and I like it. Maybe this is also thought of here, 
but what if the cube rotations were increasingly random with 
increasingly darker colours? Might not be a good idea, but....

-- 
Thomas

[Ilya Razmanov] Re: Upd: not only spheres [820 days 20 hours and 57 minutes ago]

Sat, 13 Jan 2024 08:44:26 GMT

Sorry, wrong picture. Now attached it result of "b4zaikaR" with default 
setting. Source image is also attached. I hope it sort of shows the idea 
I had in mind when starting it.

On 12.01.2024 17:02, Ilya Razmanov wrote:
> Hi,
> 
> I finally added some system to that Python stuff for image to POVRay 
> conversion, so now it, by default, turns image pixels into either 
> spheres or boxes, rotates and scales them somehow, covers both C3 and C4 
> symmetry (well, actally with options for C2), and mostly resides here:
> 
> https://github.com/Dnyarri/POVmosaic
> 
> and here:
> 
> https://gitflic.ru/project/dnyarri/povmosaic
> 
> Attached is a casual rendering with default settings just to capture 
> your attention.

[Ilya Razmanov] Upd: not only spheres (was: Converting image pix... [821 days 15 hours and 38 minutes ago]

Fri, 12 Jan 2024 14:02:58 GMT

Hi,

I finally added some system to that Python stuff for image to POVRay 
conversion, so now it, by default, turns image pixels into either 
spheres or boxes, rotates and scales them somehow, covers both C3 and C4 
symmetry (well, actally with options for C2), and mostly resides here:

https://github.com/Dnyarri/POVmosaic

and here:

https://gitflic.ru/project/dnyarri/povmosaic

Attached is a casual rendering with default settings just to capture 
your attention.

[Ilya Razmanov] Version update (was Re: Height field to mesh - m... [842 days 1 hour and 25 minutes ago]

Sat, 23 Dec 2023 04:15:54 GMT

On 30.11.2023 7:59, Ilya Razmanov wrote:

> Meanwhile, I hope someone will find this tiny utility useful, and 
> probably even come with new ideas.
While discussion in general switched to using of POVRay SDL, I guess 
I'll still share the update of initial Python utility, including some 
small bugfixes and stuff.

To reduce my contribution into wasting this server storage space, I 
decided to waste github space instead, so from now on you can download 
updated versions from:

https://github.com/Dnyarri/img2mesh

Ilya

[Ilya Razmanov] Height field to mesh - more resolution [865 days and 42 minutes ago]

Thu, 30 Nov 2023 04:59:05 GMT

Greeting,

continuing experiments with Python (which continues to piss me off), I 
decided to write small program to convert image heightfields into 
triangle meshes. My may intention was to improve quality for 
heightfields having both small image size and low bit depth - I supposed 
that converting them into meshes will make POVRay interpolate 
nonexisting data, thus improving visual appearance.

Attached is my test image 1.test grey 001.png, used as a heightfield 
(with "smooth" on) for rendering 2.heightfield.jpg. Since the source is 
only 64 * 64 pixels, result looks... well, correspondingly.

Next, I created my converter (attached as img2mesh.01.004.py.bz2) and 
used it to convert the same source into triangle mesh. Rendering result 
is attached as 3.img2mesh.01.004.jpg and, as you can see, it's clearer 
but full of holes. After that I finally took a look at POVRay docs, that 
say that POVRay internally uses 4 pixels for 2 triangles, just like my 
program (never read docs before doing something yourself - it's 
discouraging!), except for I didn't do force connection of square 
corners, that lead to a holes. Instead of fixing it (I find fixing 
discouraging too), I simply invented different approach - using 4 pixels 
for 4 triangles (don't tell me if this is described somewhere already), 
that lead to a completely different program, attached as 
img2mesh.02.001.py.bz2), which provides output like attached 
4.img2mesh.02.001.jpg.

The latter looks to me significantly better than POVRay heightfield 
rendering (not to mention my first attempt), although I plan some 
additional explorations (artifacts on flat surfaces are still 
unexplained, and I even start to suspect POVRay roundoff errors).

Meanwhile, I hope someone will find this tiny utility useful, and 
probably even come with new ideas.

Prerequisites:

1) Python (I used 3.12 but previous versions of Python 3 are supposed to 
be fine). Seem to be preinstalled on many computers nowadays (that's how 
I got it, for example). My program is equipped with minimal GUI, using 
tkinter, which seem to be redistributed with all standard Python 
distributions, so doesn't require separate download.
2) Pillow for reading images. As a simple image reading library, pillow 
is distributed everywhere; at worst, it takes few seconds to download 
and no seconds to install and configure.

So, have a day.

Ilya

[Ilya Razmanov] Converting image pixels into POV-Ray spheres [869 days 2 hours and 26 minutes ago]

Sun, 26 Nov 2023 03:14:59 GMT

Greetings,

I rewrote one of my old plugins turning it into Python program. The 
program read images (like PNG) and convert them into POV-Ray scene 
consisting of packed spheres, each sphere having a base color of 
corresponding pixel. Since Python nowadays seem to be preinstalled on 
almost any computer, I assume it makes my old program cross-platform. 
Hopefully someone will find it suitable for something. Just one warning: 
it turns one source pixel into a POV sphere supposed to be rendered 
relatively big, so start testing it with small source images.

Have fun,

Ilya

[Mike Miller] Re: OBJ to POV smooth triangles [873 days 1 hour and 56 minutes ago]

Wed, 22 Nov 2023 03:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > I was looking for an OBJ to POV converter and keep hitting a dead end. So, I
> > wrote this simple one to handle some complex modeling in Blender. If someone
> > knows of one, I'd like to test it.
> > Miller
>
> Have you looked into Pose-Ray?

I have not...but I will. Thanks!

[Bald Eagle] Re: OBJ to POV smooth triangles [873 days 6 hours and 31 minutes ago]

Tue, 21 Nov 2023 23:10:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> I was looking for an OBJ to POV converter and keep hitting a dead end. So, I
> wrote this simple one to handle some complex modeling in Blender. If someone
> knows of one, I'd like to test it.
> Miller

Have you looked into Pose-Ray?

[Mike Miller] OBJ to POV smooth triangles [873 days 6 hours and 56 minutes ago]

Tue, 21 Nov 2023 22:45:00 GMT

Small utility that converts .obj files to POV smooth triangles. Currently
doesn't handle the texture coordinates for materials. Requires the mesh to be
triangulated and under 100,000 vertices.

I was looking for an OBJ to POV converter and keep hitting a dead end. So, I
wrote this simple one to handle some complex modeling in Blender. If someone
knows of one, I'd like to test it.
Miller

[And] Re: Wood program but still develop [908 days 21 hours and 46 minutes ago]

Tue, 17 Oct 2023 07:55:00 GMT

I think I should learn Javafx first to rewrite it. My knowledge of design
program is not enough.

[Bald Eagle] Re: Wood program but still develop [942 days 12 hours and 16 minutes ago]

Wed, 13 Sep 2023 17:25:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

> How do you get such black spalting?

#declare Crack1 =
color_map {
 [0.00 rgb 1]
 [0.50 rgb 1]
 [0.50 rgb 0]
 [0.55 rgb 0]
 [0.51 rgb 1]
 [1.00 rgb 1]
}

#declare Spalting = function {pigment {leopard turbulence 1 color_map {Crack1}}}

[And] Re: Wood program but still develop [942 days 17 hours and 6 minutes ago]

Wed, 13 Sep 2023 12:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I have to tell you, this is a tough problem, to make a fully procedural wood
> texture.
>

No no...
Make a fully procedural wood texture is interesting to me. It is keep my
attention these days.

> I think a lot of things have to be "fixed" in order to get good results - like
> color-map cycling, the behaviour of the modulo operator across the origin, and
> the domain of user generated functions.
>

I solved color-map cycling by creating main part of pigment (using function) ,
such function change its value from 0~1~0 every year. It has been done, so I
don't concern it anymore.

"The domain of user generated function" means I needs provide something flexible
for user to apply their own function. Before that time I can offer the standard
function which I developed.

> I got a very rough simulation, but it's a layered texture, to get the checking
> (cracks) and spalting.
>

How do you get such black spalting?

> To get a better wood, there would have to be knots and burls in 3D so that it
> could also be used as an isosurface.
>
> - BW

I will add knots in my output pigment pattern when I prepare enough code. But
they are just pattern, not a 3D shape.

[Bald Eagle] Re: Wood program but still develop [951 days 5 hours and 31 minutes ago]

Tue, 5 Sep 2023 00:10:00 GMT

I have to tell you, this is a tough problem, to make a fully procedural wood
texture.

I think a lot of things have to be "fixed" in order to get good results - like
color-map cycling, the behaviour of the modulo operator across the origin, and
the domain of user generated functions.

I got a very rough simulation, but it's a layered texture, to get the checking
(cracks) and spalting.

To get a better wood, there would have to be knots and burls in 3D so that it
could also be used as an isosurface.

- BW

[Bald Eagle] Re: Wood program but still develop [954 days 11 hours and 46 minutes ago]

Fri, 1 Sep 2023 17:55:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

> Wow!
> Are you an expert of chemical?

Sorta.  I have a chemistry degree, went to pharmacy school, and did most of a
PhD in Organic Chemistry and Mechanistic Enzymology.

But the real practical knowledge of that stuff comes from knowing people who
work with and restore antiques (million-dollar board-room table type things),
and working with professional painters.

There are a lot of great furniture restoration channels on YouTube that I'm sure
would cover some of what happens to finishes and what can be done to
repair/restore them.

> Maybe my program can automatically pick them(the parameter of control where the
> large-value color-block appear), fitting the shape of the woodgrain
> angular-shape curve you make. I think maybe they have relation...

Perhaps TOK or Bill Pokorny might have some ideas.
There may be some useful code in the newsgroup archives from people like Tek,
Zeger Knaepen, and other who have written mind-bogglingly complex code.
Also, you should check out the Shadertoy website and see how people are coding
their patterns, since it will let you see how they build very complex patterns
from a collection of much simpler equations.
It might also be worth contacting Martijn Steinrucker (Art of Code) or Inigo
Quilez to see if they have any ideas for how to model a really excellent and
realistic wood-grain pattern.

- BW

[And] Re: Wood program but still develop [954 days 20 hours and 56 minutes ago]

Fri, 1 Sep 2023 08:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > And then, anyone know why the wood grains becomes so white(or ever saw the same
> > ) on my last post image(dsc_0814)? I don't know why.
>
> What you're seeing there is oxidation of the paint, or a frosting or "bloom"
> from when solvent gets on the surface and dissolves out some of the clear
> binder, or when water gets on the paint and hydrates/swells the surface coating,
> which I believe causes it to develop microscopic cracks, allowing air in, and
> giving it a different IOR.
> Kind of like taking transparent tape and putting it on a dark surface - it's not
> transparent until you rub/burnish it down to exclude all of the air between the
> tape and the surface.

Wow!
Are you an expert of chemical?

>
> > ------------------------------------------------------------------
> > If I can simulate the most of the wood pattern detail like this attached pic
>
> I think that what might have to happen is to have a variety of functions that
> get interpolated across the surface of the wood, to give rise to a smooth
> blending of different patterns.   Right now you're just sort of unioning them.
>
> > I have many reasons.
> > The one reason is that I need correct information about the f_bumps pattern.
>
> What needs to be corrected?

Because I found many beautiful pattern this week, including something
radial-randomize or circular-randomize bump pattern. They are useful and play an
important role.
Maybe my program can automatically pick them(the parameter of control where the
large-value color-block appear), fitting the shape of the woodgrain
angular-shape curve you make. I think maybe they have relation...

[Bald Eagle] Re: Wood program but still develop [955 days 7 hours and 36 minutes ago]

Thu, 31 Aug 2023 22:05:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> And then, anyone know why the wood grains becomes so white(or ever saw the same
> ) on my last post image(dsc_0814)? I don't know why.

What you're seeing there is oxidation of the paint, or a frosting or "bloom"
from when solvent gets on the surface and dissolves out some of the clear
binder, or when water gets on the paint and hydrates/swells the surface coating,
which I believe causes it to develop microscopic cracks, allowing air in, and
giving it a different IOR.
Kind of like taking transparent tape and putting it on a dark surface - it's not
transparent until you rub/burnish it down to exclude all of the air between the
tape and the surface.

> ------------------------------------------------------------------
> If I can simulate the most of the wood pattern detail like this attached pic

I think that what might have to happen is to have a variety of functions that
get interpolated across the surface of the wood, to give rise to a smooth
blending of different patterns.   Right now you're just sort of unioning them.

> I have many reasons.
> The one reason is that I need correct information about the f_bumps pattern.

What needs to be corrected?

- BW

[And] Re: Wood program but still develop [955 days 14 hours and 31 minutes ago]

Thu, 31 Aug 2023 15:10:00 GMT

And then, anyone know why the wood grains becomes so white(or ever saw the same
) on my last post image(dsc_0814)? I don't know why.

------------------------------------------------------------------
If I can simulate the most of the wood pattern detail like this attached pic
(the
desk has been thrown away...) one day, my program will be valuable.
------------------------------------------------------------------

In the future I need to learn something about call/invoke POV-Ray in another
program.

I have many reasons.
The one reason is that I need correct information about the f_bumps pattern.
Another is preview, but not only preview.

[And] Re: Wood program but still develop [957 days 14 hours and 26 minutes ago]

Tue, 29 Aug 2023 15:15:00 GMT

I got several wood plunk 2~3 weeks ago from my grandmother's furnitures. She is
just pass away one month ago.
I collect some of the wood, look them and thinking. So far I feel I have
collected enough idea of my wood texture generator program I want to make.

I sign up a computer lesson to learn spring framework (about Java programming
languish) September. If everything well, I will rewrite some component(with Java
program) after learning that lesson.
I wish the wood texture program become sufficient good after developing.

I have found some good method to generate bumps associate pattern for making
complex pattern these days. So I'm preparing.

But I need some career planing (suggestion, ...), too. Because I delay something
important on my life again and again...

[Mike Miller] Re: Exporting tools [1132 days 3 hours and 56 minutes ago]

Wed, 8 Mar 2023 01:45:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 06/03/2023 07:02, Mike Miller wrote:
> > liking the results. Attached is one of the materials I'm messing with.
> Hi, Mike.
> Really nice, also I like the stones at the right, they are looks like
> wet and slick.
> --
> YB

Thanks YB,
I've been messing around with layered materials - stacking normals and
transparency that aligns to the color map. Attached is a fish 14 rendering using
them some the blobby muddy and the painted pipe.
Mike

[yesbird] Re: Exporting tools [1134 days 1 hour and 8 minutes ago]

Mon, 6 Mar 2023 04:33:45 GMT

On 06/03/2023 07:02, Mike Miller wrote:
> liking the results. Attached is one of the materials I'm messing with.
Hi, Mike.
Really nice, also I like the stones at the right, they are looks like
wet and slick.
--
YB

[Mike Miller] Re: Exporting tools [1134 days 1 hour and 36 minutes ago]

Mon, 6 Mar 2023 04:05:00 GMT

Paolo Gibellini <p.g### [at] gmailcom> wrote:
> Il 04/03/2023 23:34, Mike Miller wrote:
> > Attached is my latest fish model floating around some pipes from a chemical
> > spill.  ...we just had a chemical spill over into Ohio..haha. It started as an
> > underwater scene, but I added a reflection pool so I'm not sure where this is
> > going. It's a work in progress but I like the rendering so far - so I'm posting
> > it.
> >
> > Mike.
>
> Nice image!
>
> Paolo

Thanks Paolo,
I'm currently updating the topo mud/blob textures for that image...I felt the
material got too busy at certain distances. Looking at pigment_pattern/color_map
inside the texture normal to control bumps within darker veins of the color map
-
liking the results. Attached is one of the materials I'm messing with.
Mike

[Paolo Gibellini] Re: Exporting tools [1134 days 11 hours and 3 minutes ago]

Sun, 5 Mar 2023 18:38:05 GMT

Il 04/03/2023 23:34, Mike Miller wrote:
> Attached is my latest fish model floating around some pipes from a chemical
> spill.  ...we just had a chemical spill over into Ohio..haha. It started as an
> underwater scene, but I added a reflection pool so I'm not sure where this is
> going. It's a work in progress but I like the rendering so far - so I'm posting
> it.
> 
> Mike.

Nice image!

Paolo

[yesbird] Re: Exporting tools [1134 days 15 hours and 41 minutes ago]

Sun, 5 Mar 2023 14:00:25 GMT

On 05/03/2023 16:28, Mike Miller wrote:
> I also had an odd
> behavior when rotating this part along the z and then moving in the y direction
> - it moved the part in the z instead...maybe 'gimbal-lock' ?
Hi, Mike.
I like this construction and will look at it more closely, after
completing the C4D exporter, may be able to fix it.
--
YB

[Mike Miller] Re: Exporting tools [1134 days 16 hours and 11 minutes ago]

Sun, 5 Mar 2023 13:30:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 05/03/2023 03:41, Mike Miller wrote:
> > Below is the pipe macro for the fish scene I just posted. Almost a parametric
> > object. :)
> Why almost ? Very good parameterized !
> --
> YB

Thanks,
the "flange" should probable be pre-defined as a separate object (like the bolt)
instead of being driven by some of the pipe parameters. I also had an odd
behavior when rotating this part along the z and then moving in the y direction
- it moved the part in the z instead...maybe 'gimbal-lock' ?
Mike

[yesbird] Re: Exporting tools [1135 days 3 hours and 42 minutes ago]

Sun, 5 Mar 2023 01:59:33 GMT

On 05/03/2023 03:41, Mike Miller wrote:
> Below is the pipe macro for the fish scene I just posted. Almost a parametric
> object. :)
Why almost ? Very good parameterized !
--
YB

[Mike Miller] Re: Exporting tools [1135 days 4 hours and 56 minutes ago]

Sun, 5 Mar 2023 00:45:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 05/03/2023 01:34, Mike Miller wrote:
> Hi, Mike.
> > Thank you YB! I'll definitely check that out. Love to see how you're handling
> > the data. I'm doing something similar with dxf ascii files exported from Cad.
> > Have you looked at Blender? - I've use it for FBX exports for odds and ends. Not
> > sure if vertex color can be preserved but individual objects/spheres would carry
> > a material name that could be used in a macro.
> I should say that I started to write a C4D exporter after looking at
> your workflow - POV definitely needs some external drawing tools. I used
> AutoCad 10 in 1993, writing extensions for
> ecological calculations (insolations and noise normatives in
> architecture), now C4D is my first 3D tool. Exporter is almost
> completed, I'm doing final cleanup now and hope tomorrow will be the
> first release :)
>
> > Attached is my latest fish model floating around some pipes from a chemical
> > spill.  ...we just had a chemical spill over into Ohio..haha.
> Horror ...
>
> > It started as an underwater scene, but I added a reflection pool so I'm not sure
where this is
> > going. It's a work in progress but I like the rendering so far - so I'm posting
> > it.
> Rendering is really good, and also I like to look at the development
> process in dynamics, including basic drafts, this gives me an idea of
> the author's thinking methods.
>
> Looking forward for your new posts.
> --
> YB


Thanks YB,
you started using AutoCAD before I did. :)
I bought 3DS Max in 93 and stared using AutoCAD 12 professionally in '95 or so.

Below is the pipe macro for the fish scene I just posted. Almost a parametric
object. :)






//--- pipe and flange parts
//--- miller 3.2.23
#include "shapes3.inc"


#macro pm_lathe_pipe (w,h)
    lathe{
        linear_spline
        4,
        <0, 0>,
        <0, h>,
        <w, h>,
        <w, 0>
    }
#end


#declare fill_object  = 1;
#declare merge_object = 1;

#declare pipe_height = 5;
#declare pipe_rad = 1;
#declare flange_height = 4.7;
#declare flange_rad = 2;
#declare edge_rad = .05;
#declare double_flange = 1;
#declare flange_collar = true;
#declare collar_height = .5;
#declare collar_rad = pipe_rad + .1;

#declare bolt_count = 8;
#declare bolt_sides = 6;
#declare bolt_rad = .25;
#declare bolt_height = .25;
#declare bolt_position = <pipe_rad + ((flange_rad-pipe_rad)/2),
flange_height-bolt_height, 0>  ;

#declare pipe_ribs = 3;
#declare pipe_rib_rad = .05;



//--- bolt prototype
#declare bolt =
Round_Pyramid_N_in(
    bolt_sides,
    <0,0,0>,
    bolt_rad,
    <0,bolt_height,0>,
    bolt_rad,
    edge_rad,
    fill_object,
    merge_object )

//--- bolt prototype
#declare bolt_end =
Round_Pyramid_N_in(
    bolt_sides,
    <0,0,0>,
    pipe_rad*.6,
    <0,-.25,0>,
    pipe_rad*.55,
    edge_rad,
    fill_object,
    merge_object )



#macro pipe_with_flange()
union{
    Round_Cylinder_Tube(
        <0,0,0>,
        <0,pipe_height,0>,
        pipe_rad,
        edge_rad,
        fill_object,
        merge_object )  //-- main vertical pipe

    Round_Cylinder_Tube(
        <0,flange_height,0>,
        <0,pipe_height,0>,
        flange_rad,
        edge_rad,
        fill_object,
        merge_object )  //--- top flange



    #if (double_flange = 1)
         Round_Cylinder_Tube(
            <0,pipe_height,0>,
            <0,pipe_height + (pipe_height-flange_height),0>,
            flange_rad,
            edge_rad,
            fill_object,
            merge_object )  //--- double flange

            #if (bolt_count > 0)
                #declare c=0;
                #declare inc=360/bolt_count;
                #while (c < bolt_count)
                    #declare r_y = inc*c;
                    #declare n_x = bolt_position.x ;
                    #declare n_y = bolt_position.y +
(pipe_height-flange_height)*2 + bolt_height;
                    #declare n_z = bolt_position.z ;
                    object {bolt translate <n_x, n_y, n_z> rotate y*r_y}
                    #declare c = c + 1;
                #end
            #end
    #end

    bolt_end

    #if (bolt_count > 0)
        #declare c=0;
        #declare inc=360/bolt_count;
        #while (c < bolt_count)
            #declare new_y = inc*c;
            object {bolt translate bolt_position rotate y*new_y}
            #declare c = c + 1;

        #end
    #end


    #if (pipe_ribs> 0)
        #declare c=0;
        #declare inc=flange_height/pipe_ribs;
        #while (c < pipe_ribs)
            #declare new_y = inc*c;
            torus { pipe_rad ,pipe_rib_rad translate <0,new_y,0>}
            #declare c = c + 1;

        #end
     #end

    #if (flange_collar = true)
        #declare n_y = (pipe_height -(pipe_height-flange_height)) -
collar_height ;
        Round_Cylinder_Tube(
            <0,n_y,0>,
            <0,n_y + collar_height ,0>,
            collar_rad,
            edge_rad,
            fill_object,
            merge_object )  //-- collar
     #end

      }
#end




//object { pipe_with_flange() material{some_material} scale .2 }

[yesbird] Re: Exporting tools [1135 days 5 hours and 16 minutes ago]

Sun, 5 Mar 2023 00:25:08 GMT

Btw, don't you have ready-to-publish Fish-13 with green skin like on
attached image ? I would like to add it to collection, but have troubles
with texture tweaking :(
--
YB

[yesbird] Re: Exporting tools [1135 days 5 hours and 29 minutes ago]

Sun, 5 Mar 2023 00:11:49 GMT

On 05/03/2023 01:34, Mike Miller wrote:
Hi, Mike.
> Thank you YB! I'll definitely check that out. Love to see how you're handling
> the data. I'm doing something similar with dxf ascii files exported from Cad.
> Have you looked at Blender? - I've use it for FBX exports for odds and ends. Not
> sure if vertex color can be preserved but individual objects/spheres would carry
> a material name that could be used in a macro.
I should say that I started to write a C4D exporter after looking at
your workflow - POV definitely needs some external drawing tools. I used
AutoCad 10 in 1993, writing extensions for
ecological calculations (insolations and noise normatives in
architecture), now C4D is my first 3D tool. Exporter is almost
completed, I'm doing final cleanup now and hope tomorrow will be the
first release :)

> Attached is my latest fish model floating around some pipes from a chemical
> spill.  ...we just had a chemical spill over into Ohio..haha.
Horror ...

> It started as an underwater scene, but I added a reflection pool so I'm not sure
where this is
> going. It's a work in progress but I like the rendering so far - so I'm posting
> it.
Rendering is really good, and also I like to look at the development
process in dynamics, including basic drafts, this gives me an idea of
the author's thinking methods.

Looking forward for your new posts.
--
YB

[Mike Miller] Re: Exporting tools [1135 days 7 hours and 1 minute ago]

Sat, 4 Mar 2023 22:40:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi.
> I would like to share tools for exporting data to POV/SDL format
> that I am using in my projects. To preserve flexibility, exported data
> stored in array that can be processed by macros.
>
> At present time following formats and entities are supported:
> 1. Cinema4D
> 1.1 Splines
>
> Now I'm working on exporting spheres from C4D and 'polypainted' meshes
> from ZBrush with preserving color-per-vertex information.
>
> Repository: https://github.com/syanenko/pov-utils
> --
> YB

Thank you YB! I'll definitely check that out. Love to see how you're handling
the data. I'm doing something similar with dxf ascii files exported from Cad.
Have you looked at Blender? - I've use it for FBX exports for odds and ends. Not
sure if vertex color can be preserved but individual objects/spheres would carry
a material name that could be used in a macro.

Attached is my latest fish model floating around some pipes from a chemical
spill.  ...we just had a chemical spill over into Ohio..haha. It started as an
underwater scene, but I added a reflection pool so I'm not sure where this is
going. It's a work in progress but I like the rendering so far - so I'm posting
it.

Mike.

[yesbird] Exporting tools [1136 days 12 hours and 16 minutes ago]

Fri, 3 Mar 2023 17:25:04 GMT

Hi.
I would like to share tools for exporting data to POV/SDL format
that I am using in my projects. To preserve flexibility, exported data
stored in array that can be processed by macros.

At present time following formats and entities are supported:
1. Cinema4D
1.1 Splines

Now I'm working on exporting spheres from C4D and 'polypainted' meshes
from ZBrush with preserving color-per-vertex information.

Repository: https://github.com/syanenko/pov-utils
--
YB

[And] Re: Wood design program test version [1202 days 13 hours and 1 minute ago]

Tue, 27 Dec 2022 16:40:00 GMT

During these several months I'm practicing my *basic* programming ability(mostly
by a project I'm writing for another person), and interrupt this project.
I have learned something indeed like using "generics", "breakpoint debugger",
and
a bit more programming structure such as interface.
(Java part)

I will continue this wood design project in the future(at least two-three months
after). I want to refactor many of my components of it, too.

[And] Re: Wood design program test version [1294 days 12 hours and 41 minutes ago]

Mon, 26 Sep 2022 17:00:00 GMT

..zip version

[And] Re: Wood design program test version [1294 days 12 hours and 46 minutes ago]

Mon, 26 Sep 2022 16:55:00 GMT

Hi, ...
I release a new test version here.
I freeze the curve diagram when the page uneditable.

And make an earlywood-latewood ratio editor.

I wrote many code to generate the pattern function..., instead of copy an entity
file. But looks not so different, just prepared for the future editor.

[And] Re: Wood program but still develop [1325 days 22 hours and 51 minutes ago]

Fri, 26 Aug 2022 06:50:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 23/08/2022 om 12:52 schreef Bald Eagle:
> > TdG may have code of a similar nature in his vast archive, or have other ideas
> > of his own about how to approach the branch/knot aspect of the wood pattern.
> >
>
> Not really. The best I can come up with is isowood by Christoph Hormann
>
> http://www.imagico.de/iso_wood_en.php
>
> Dan Hentschel and Nicolas Rougier did a couple of wood textures some 15
> years ago, Nicolas using black hole warps.
>
> Warp has some interesting things to say, about wood, incidentally
>
> http://warp.povusers.org/povtips/
>
>
> --
> Thomas

I visited Christoph Hormann's site long time ago. I have clear impression of it
by the natural wood appearance and color.
I know it use 'isosurface', not simple texture.

[And] Re: Wood program but still develop [1325 days 23 hours and 6 minutes ago]

Fri, 26 Aug 2022 06:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> >
> > Oh, ... I wouldn't like to make any detailed tree trunk "3D Model"(that is
> > another
> > challenge), I just generate a (3D)texture. I implement my texture in POV-Ray,
> > outputting "pigment {...}" as its final form.
>
> Naturally.  The wood pigment patterns we've almost all been using for the past
> 30 years are just a bunch of concentric cylindrical rings.   Seems to work well
> enough for most purposes.
> To add a bit of realism by simulating the cross-section of those 3D branches,
> the black hole warp can be used, and that's what I was thinking when I suggested
> looking this over - not copying the paper's method verbatim.
>
> So rather than create a whole 3D tree and then slice it (which would necessarily
> limit the pattern to the locus of the individually modeled tree), I was thinking
> that you could assemble a pattern of black hole warps using an L-system in code,
> which would then be used to define the pigment {}.

I just notice "black hole warps" this time. It seems it is a 'spherical'
distortion around a sphere-center?

However, I can make more natural knot shape by myself. I use function as pigment
input, it is more flexible than the built-in pigment-warp of POV-Ray. I still
need several months to integrate it with my GUI java program. But I will
investigate this feature(black_hole warp) for it being a convenient effect.


>
> I my mind, this would be very much like the way Tor Olav Kristensen uses a macro
> to assemble the terms of a long Bernstein polynomial function.
>

'Bernstein polynomial function' looks like some special function I know, but I
don't know this one.


> jr has also done a lot of development using the method of including the parsed
> text of temporary files to assemble complex data/code structures, as well as
> some pretty complex data "trees" - which might serve as inspiration to you or
> others for generating complex pigment pattern definitions.

Oh, jr had e-mail me and told me something, thereby I fix the 'locale' problem
of number quickly last time.


>
> TdG may have code of a similar nature in his vast archive, or have other ideas
> of his own about how to approach the branch/knot aspect of the wood pattern.

[Thomas de Groot] Re: Wood program but still develop [1327 days 22 hours and 51 minutes ago]

Wed, 24 Aug 2022 06:49:54 GMT

Op 23/08/2022 om 12:52 schreef Bald Eagle:
> TdG may have code of a similar nature in his vast archive, or have other ideas
> of his own about how to approach the branch/knot aspect of the wood pattern.
> 

Not really. The best I can come up with is isowood by Christoph Hormann

http://www.imagico.de/iso_wood_en.php

Dan Hentschel and Nicolas Rougier did a couple of wood textures some 15 
years ago, Nicolas using black hole warps.

Warp has some interesting things to say, about wood, incidentally

http://warp.povusers.org/povtips/


-- 
Thomas

[Bald Eagle] Re: Wood program but still develop [1328 days 18 hours and 46 minutes ago]

Tue, 23 Aug 2022 10:55:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "And" <49341109@ntnu.edu.tw> wrote:
> >
> > I didn't read this paper (yet), but it just showed up in my email inbox.
> > Maybe it will inspire some ideas, serve as an entry to other similar research
> > papers, and be of some practical use in developing your challenging project.
> >
> > (I hadn't thought of using L-systems!)
> >
> > -BW
> >
> >
>
>
> Oh, ... I wouldn't like to make any detailed tree trunk "3D Model"(that is
> another
> challenge), I just generate a (3D)texture. I implement my texture in POV-Ray,
> outputting "pigment {...}" as its final form.

Naturally.  The wood pigment patterns we've almost all been using for the past
30 years are just a bunch of concentric cylindrical rings.   Seems to work well
enough for most purposes.
To add a bit of realism by simulating the cross-section of those 3D branches,
the black hole warp can be used, and that's what I was thinking when I suggested
looking this over - not copying the paper's method verbatim.

So rather than create a whole 3D tree and then slice it (which would necessarily
limit the pattern to the locus of the individually modeled tree), I was thinking
that you could assemble a pattern of black hole warps using an L-system in code,
which would then be used to define the pigment {}.

I my mind, this would be very much like the way Tor Olav Kristensen uses a macro
to assemble the terms of a long Bernstein polynomial function.

jr has also done a lot of development using the method of including the parsed
text of temporary files to assemble complex data/code structures, as well as
some pretty complex data "trees" - which might serve as inspiration to you or
others for generating complex pigment pattern definitions.

TdG may have code of a similar nature in his vast archive, or have other ideas
of his own about how to approach the branch/knot aspect of the wood pattern.

[And] Re: Wood program but still develop [1328 days 19 hours and 56 minutes ago]

Tue, 23 Aug 2022 09:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
> I didn't read this paper (yet), but it just showed up in my email inbox.
> Maybe it will inspire some ideas, serve as an entry to other similar research
> papers, and be of some practical use in developing your challenging project.
>
> (I hadn't thought of using L-systems!)
>
> -BW
>
>

Oh, ... I wouldn't like to make any detailed tree trunk "3D Model"(that is
another
challenge), I just generate a (3D)texture. I implement my texture in POV-Ray,
outputing "pigment {...}" as its final form.

Maybe I will release that next version in two - three weeks, I have completed a
little bit new feature, which can adjust earlywood-latewood ratio(varying during
year) as you suggest.

[Bald Eagle] Re: Wood program but still develop [1338 days 2 hours and 46 minutes ago]

Sun, 14 Aug 2022 02:55:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

I didn't read this paper (yet), but it just showed up in my email inbox.
Maybe it will inspire some ideas, serve as an entry to other similar research
papers, and be of some practical use in developing your challenging project.

(I hadn't thought of using L-systems!)

-BW

https://www.academia.edu/keypass/TklERytmOFYyc2ZaWDhzZ2lKd1p2RzlPdVR5SFQ3OC9wZVB0NzAvOFI2bz0tLUdSbDRQT1R4dFpCVEFBV1lRWm
Naamc9PQ==--4e10a79e4ba8dd769635ce68308bdbcc2e9e8f3f/t/jZTSw-QwzUMmQ-CC8f8/resource/work/23491795/3Gmap_L_systems_an_ap
plication_to_the_modelling_of_wood?email_work_card=view-paper&li=0

[And] Re: Wood design program test version [1368 days 22 hours and 46 minutes ago]

Thu, 14 Jul 2022 06:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "And" <49341109@ntnu.edu.tw> wrote:
> > I fix it and attach a new version.
> > No any other change, besides adding axis on the angular-shape-editor for
> > identify the direction.
>
> works, thanks.  now need to find time to play.  cheers.
>
>
> regards, jr.

Glad to hear that works.

[jr] Re: Wood design program test version [1369 days 21 hours and 6 minutes ago]

Wed, 13 Jul 2022 08:35:00 GMT

hi,

"And" <49341109@ntnu.edu.tw> wrote:
> I fix it and attach a new version.
> No any other change, besides adding axis on the angular-shape-editor for
> identify the direction.

works, thanks.  now need to find time to play.  cheers.


regards, jr.

[And] Re: Wood design program test version [1369 days 22 hours and 21 minutes ago]

Wed, 13 Jul 2022 07:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> (it is a day for "bugs", it seems :-))
>
>
> "And" <49341109@ntnu.edu.tw> wrote:
> > Thomas de Groot <tho### [at] degrootorg> wrote:
> > > ...
> > > Next, I shall try to give my views/ideas on the layout, comprehensive
> > > use, etc, of the application.
>
> tells me it works on MS Windows, but not (for me) on Linux (like 'rtr' </sigh>).
>
> after exiting the program and changing into the 'example1' directory, POV-Ray
> does not like the spaces in the file name, so when:
>
>   $ povparse +i"show tree function.pov"
>
> Problem with option setting
> /usr/local/bin/povray-3.8.0-beta.2 +w32 +h32 -d -f -p -gr -gs +ishow tree
> function.pov
> Failed to parse command-line option
>
> another error occurs because the 'pretrace_*' settings depend on image size, eg
> with the (small) WxH settings above.
>
> however, file renamed and using a large enough WxH, I get another error.  not
> even sure what the problem is supposed to be (since the code looks kosher (to
> the untutored eye)):
>
> File 'functions.inc' line 9: Parse Warning: Scene language version changed after
>  a 'default' statement. The changes in defaults normally associated with the
>  language version change are not applied.
> File 'example1_angular_shape_factor.inc' line 10: Possible Parse Error:
>  Suspicious identifier found in function! If you want to call a function make
>  sure the function you call has been declared. If you call an internal function,
>  make sure you have included 'functions.inc'.
> File 'example1_angular_shape_factor.inc' line 10: Parse Error: Expected
>  'operator', ( found instead
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> regards, jr.


Thanks.
It should copy some text but it didn't.
(I should use \ not // for the file path connect)

I fix it and attach a new version.
No any other change, besides adding axis on the angular-shape-editor for
identify the direction.

[jr] Re: Wood design program test version [1370 days 18 hours and 6 minutes ago]

Tue, 12 Jul 2022 11:35:00 GMT

hi,

(it is a day for "bugs", it seems :-))

"And" <49341109@ntnu.edu.tw> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > ...
> > Next, I shall try to give my views/ideas on the layout, comprehensive
> > use, etc, of the application.

tells me it works on MS Windows, but not (for me) on Linux (like 'rtr' </sigh>).

after exiting the program and changing into the 'example1' directory, POV-Ray
does not like the spaces in the file name, so when:

  $ povparse +i"show tree function.pov"

Problem with option setting
/usr/local/bin/povray-3.8.0-beta.2 +w32 +h32 -d -f -p -gr -gs +ishow tree
function.pov
Failed to parse command-line option

another error occurs because the 'pretrace_*' settings depend on image size, eg
with the (small) WxH settings above.

however, file renamed and using a large enough WxH, I get another error.  not
even sure what the problem is supposed to be (since the code looks kosher (to
the untutored eye)):

File 'functions.inc' line 9: Parse Warning: Scene language version changed after
 a 'default' statement. The changes in defaults normally associated with the
 language version change are not applied.
File 'example1_angular_shape_factor.inc' line 10: Possible Parse Error:
 Suspicious identifier found in function! If you want to call a function make
 sure the function you call has been declared. If you call an internal function,
 make sure you have included 'functions.inc'.
File 'example1_angular_shape_factor.inc' line 10: Parse Error: Expected
 'operator', ( found instead
Fatal error in parser: Cannot parse input.
Render failed

regards, jr.

[And] Re: Wood design program test version [1374 days 21 hours and 56 minutes ago]

Fri, 8 Jul 2022 07:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> I guess that those numbers may change with the input by the user (I did
> not see that happen, though). You know best where those particular
> numbers come from.
>

I have not finished that scheme yet. In fact, the GUI for controlling the
detailed pattern doesn't start to be designed.
You can change that part (..._bumps_pattern_detail.inc) yourself. If my memory
serves me right, the functions produced here is prepare for the
"tree_colormap_temp_file.inc" only. I will try different combines, too.

> Next, I shall try to give my views/ideas on the layout, comprehensive
> use, etc, of the application.
>
> --
> Thomas

:)

[And] Re: Wood design program test version [1374 days 22 hours and 11 minutes ago]

Fri, 8 Jul 2022 07:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Almost error-free! :-)
>
> In output file: example1_bumps_pattern_detail.inc  there are still five
> instances of offensive comma's that need to be replaced by dots. I show
> them here below with an arrow:
>
> //----start code----
> #include "bumps_detail_pattern_macros.inc"
> #declare f_height_for_bumps_extent =
> generate_bump_follow_height_trend_f(20.0);
>
> // ------------ fiber ------------
> #declare f_thin_fiber_mockup0 =
> generate_thin_circled_pattern_f_input_t_theta_h(
> 10.0, 60.0, 3.0, 3.0, 0.015, 5,
> 0.007, 0,32,                      <=== 0,32 should be 0.32
> 0.00, 2.50, 0.14, 0.15,
> seed(44),
> 0.014, 20.00
> );
>
> #declare f_thin_fiber_mockup1 =
> generate_thin_circled_pattern_f_input_t_theta_h(
> 10.0, 60.0, 3.0, 3.0, 0.017, 4,
> 0.011, 0,32,                      <=== 0,32 should be 0.32
> 0.00, 2.50, 0.14, 0.15,
> seed(45),
> 0.014, 20.00
> );
>
>
> #declare f_thin_fiber =
> function(x, y, z, time_value) {
> +0,50*f_thin_fiber_mockup0(           <=== 0,50 should be 0.50
>      time_value,
>      f_theta(x,y),
>      f_height_for_bumps_extent(x, y, z)
> )
> +0,50*f_thin_fiber_mockup1(           <=== 0,50 should be 0.50
>      time_value,
>      f_theta(x,y),
>      f_height_for_bumps_extent(x, y, z)
> )
> }
>
> // ------------- large color ---------------------------
>
> #declare f_large_color_block_mockup =
> generate_thin_circled_pattern_f_input_t_theta_h(
> 10.0, 60.0, 3.0, 3.0, 2.32, 4,
> 0.144, 0,32,                      <=== 0,32 should be 0.32
> 0.00, 2.50, 0.14, 0.15,
> seed(25),
> 0.014, 20.00
> );
>
> #declare f_large_color_block =
> function(x, y, z, time_value) {
> f_adjust_sharp_distribution(
>      x, y, z,
>      f_large_color_block_mockup(
>          time_value,
>          f_theta(x,y),
>          f_height_for_bumps_extent(x, y, z)
>      )
> )
> }
> //----end code----
>
> With these corrected, the application works!


Yes, I correct it now..
I correct another problem for ...maybe non-windows system cannot output files
when click that "output" button. But need to be tried.

And I add an "exit" function in a menu.

[Thomas de Groot] Re: Wood design program test version [1375 days 13 hours and 51 minutes ago]

Thu, 7 Jul 2022 15:50:14 GMT

Forgot to mention, I used your version WoodDesignProgram alpha ver20220705.

-- 
Thomas

[Thomas de Groot] Re: Wood design program test version [1375 days 13 hours and 58 minutes ago]

Thu, 7 Jul 2022 15:42:49 GMT

Almost error-free! :-)

In output file: example1_bumps_pattern_detail.inc  there are still five 
instances of offensive comma's that need to be replaced by dots. I show 
them here below with an arrow:

//----start code----
#include "bumps_detail_pattern_macros.inc"
#declare f_height_for_bumps_extent =
generate_bump_follow_height_trend_f(20.0);

// ------------ fiber ------------
#declare f_thin_fiber_mockup0 =
generate_thin_circled_pattern_f_input_t_theta_h(
10.0, 60.0, 3.0, 3.0, 0.015, 5,
0.007, 0,32,                      <=== 0,32 should be 0.32
0.00, 2.50, 0.14, 0.15,
seed(44),
0.014, 20.00
);

#declare f_thin_fiber_mockup1 =
generate_thin_circled_pattern_f_input_t_theta_h(
10.0, 60.0, 3.0, 3.0, 0.017, 4,
0.011, 0,32,                      <=== 0,32 should be 0.32
0.00, 2.50, 0.14, 0.15,
seed(45),
0.014, 20.00
);


#declare f_thin_fiber =
function(x, y, z, time_value) {
+0,50*f_thin_fiber_mockup0(           <=== 0,50 should be 0.50
     time_value,
     f_theta(x,y),
     f_height_for_bumps_extent(x, y, z)
)
+0,50*f_thin_fiber_mockup1(           <=== 0,50 should be 0.50
     time_value,
     f_theta(x,y),
     f_height_for_bumps_extent(x, y, z)
)
}

// ------------- large color ---------------------------

#declare f_large_color_block_mockup =
generate_thin_circled_pattern_f_input_t_theta_h(
10.0, 60.0, 3.0, 3.0, 2.32, 4,
0.144, 0,32,                      <=== 0,32 should be 0.32
0.00, 2.50, 0.14, 0.15,
seed(25),
0.014, 20.00
);

#declare f_large_color_block =
function(x, y, z, time_value) {
f_adjust_sharp_distribution(
     x, y, z,
     f_large_color_block_mockup(
         time_value,
         f_theta(x,y),
         f_height_for_bumps_extent(x, y, z)
     )
)
}
//----end code----

With these corrected, the application works!

I guess that those numbers may change with the input by the user (I did 
not see that happen, though). You know best where those particular 
numbers come from.

Next, I shall try to give my views/ideas on the layout, comprehensive 
use, etc, of the application.

-- 
Thomas

[And] Re: Wood design program test version [1376 days 15 hours and 21 minutes ago]

Wed, 6 Jul 2022 14:20:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 05/07/2022 om 09:29 schreef And:
>
> > I'm not clear this time. POV-Ray cannot use a number contains commas as you
> > said, why I need add commas between every step of 10^3. I attach a picture, this
> > picture is what I saw on my output data. Is the same format on your output data?
> >
>
> This looks ok to me and is what I expected.
>
> --
> Thomas

That's great.

[Thomas de Groot] Re: Wood design program test version [1376 days 23 hours and 23 minutes ago]

Wed, 6 Jul 2022 06:18:09 GMT

Op 05/07/2022 om 09:29 schreef And:

> I'm not clear this time. POV-Ray cannot use a number contains commas as you
> said, why I need add commas between every step of 10^3. I attach a picture, this
> picture is what I saw on my output data. Is the same format on your output data?
> 

This looks ok to me and is what I expected.

-- 
Thomas

[And] Re: Wood design program test version [1377 days 13 hours and 26 minutes ago]

Tue, 5 Jul 2022 16:15:00 GMT

compress to .zip

[And] Re: Wood design program test version [1377 days 13 hours and 26 minutes ago]

Tue, 5 Jul 2022 16:15:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> The length units I use are from the metric system; whether they are mm,
> cm, m, or km, is of no importance and only relevant within a given scene
> of course.
>
> Where things go wrong, starts with the exported ****_radial_speed.inc
> file where
>
> #local r_pos = array[7][4] {
> { 0,00, 0,053815, 0,10493, 0,161445 },
> { 0,161445, 0,217235, 0,273236, 0,336914 },
> { 0,336914, 0,397284, 0,47667, 0,533589 },
> { 0,533589, 0,571795, 0,600867, 0,622288 },
> { 0,622288, 0,662945, 0,675592, 0,719823 },
> { 0,719823, 0,749311, 0,79926, 0,843443 },
> { 0,843443, 0,891902, 0,946315, 0,99775 },
> }
>
> #local year_pos = array[7][4] {
> { 0,00, 2,60, 5,20, 7,80 },
> { 7,80, 10,366667, 12,933333, 15,50 },
> { 15,50, 17,933333, 20,366667, 22,80 },
> { 22,80, 24,433333, 26,066667, 27,70 },
> { 27,70, 30,80, 33,90, 37,00 },
> { 37,00, 39,066667, 41,133333, 43,20 },
> { 43,20, 45,466667, 47,733333, 50,00 },
> }
>
> and all other exported include files where something like this is
> written. POV-Ray does not like it. :-)
>
> It would be OK if this were:
>
> #local r_pos = array[7][4] {
> { 0.00, 0.053815, 0.10493, 0.161445 },
> { 0.161445, 0.217235, 0.273236, 0.336914 },
> { 0.336914, 0.397284, 0.47667, 0.533589 },
> { 0.533589, 0.571795, 0.600867, 0.622288 },
> { 0.622288, 0.662945, 0.675592, 0.719823 },
> { 0.719823, 0.749311, 0.79926, 0.843443 },
> { 0.843443, 0.891902, 0.946315, 0.99775 },
> }
>
> #local year_pos = array[7][4] {
> { 0.00, 2.60, 5.20, 7.80 },
> { 7.80, 10.366667, 12.933333, 15.50 },
> { 15.50, 17.933333, 20.366667, 22.80 },
> { 22.80, 24.433333, 26.066667, 27.70 },
> { 27.70, 30.80, 33.90, 37.00 },
> { 37.00, 39.066667, 41.133333, 43.20 },
> { 43.20, 45.466667, 47.733333, 50.00 },
> }
>
> which, I suppose, is what you intend.
>
> --
> Thomas


Oh, this is important. I just fix it(but need you testing). Thank you.

No any other change. except in demo scene, I rotate<0,0,0> instead of
rotate<0,0,90> the wood-block.

[Thomas de Groot] Re: Wood design program test version [1377 days 17 hours and 53 minutes ago]

Tue, 5 Jul 2022 11:47:49 GMT

Op 5-7-2022 om 09:53 schreef And:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Exactly. The issue here is whether the 'comma' represents a 'Thousands
>> separator' (example: 3,943,200.00) or - and I guess this is what is
>> intended here - the 'decimal dot' (example: 3943200,00). Neither can be
>> used by POV-Ray.
>>
> 
>>
>> As far as I understand this issue, the use of 'thousands separators' is
>> only a visually attractive(?) trick, while calculations on those numbers
>> ignore them (obviously). My advice would be to drop them altogether,
>> especially for input to POV-Ray.
>>
>> --
>> Thomas
> 
> What the length unit does you use? Because my outputting number is usually small
> with this program(while meter is the length unit).
> 
The length units I use are from the metric system; whether they are mm, 
cm, m, or km, is of no importance and only relevant within a given scene 
of course.

Where things go wrong, starts with the exported ****_radial_speed.inc 
file where

#local r_pos = array[7][4] {
{ 0,00, 0,053815, 0,10493, 0,161445 },
{ 0,161445, 0,217235, 0,273236, 0,336914 },
{ 0,336914, 0,397284, 0,47667, 0,533589 },
{ 0,533589, 0,571795, 0,600867, 0,622288 },
{ 0,622288, 0,662945, 0,675592, 0,719823 },
{ 0,719823, 0,749311, 0,79926, 0,843443 },
{ 0,843443, 0,891902, 0,946315, 0,99775 },
}

#local year_pos = array[7][4] {
{ 0,00, 2,60, 5,20, 7,80 },
{ 7,80, 10,366667, 12,933333, 15,50 },
{ 15,50, 17,933333, 20,366667, 22,80 },
{ 22,80, 24,433333, 26,066667, 27,70 },
{ 27,70, 30,80, 33,90, 37,00 },
{ 37,00, 39,066667, 41,133333, 43,20 },
{ 43,20, 45,466667, 47,733333, 50,00 },
}

and all other exported include files where something like this is 
written. POV-Ray does not like it. :-)

It would be OK if this were:

#local r_pos = array[7][4] {
{ 0.00, 0.053815, 0.10493, 0.161445 },
{ 0.161445, 0.217235, 0.273236, 0.336914 },
{ 0.336914, 0.397284, 0.47667, 0.533589 },
{ 0.533589, 0.571795, 0.600867, 0.622288 },
{ 0.622288, 0.662945, 0.675592, 0.719823 },
{ 0.719823, 0.749311, 0.79926, 0.843443 },
{ 0.843443, 0.891902, 0.946315, 0.99775 },
}

#local year_pos = array[7][4] {
{ 0.00, 2.60, 5.20, 7.80 },
{ 7.80, 10.366667, 12.933333, 15.50 },
{ 15.50, 17.933333, 20.366667, 22.80 },
{ 22.80, 24.433333, 26.066667, 27.70 },
{ 27.70, 30.80, 33.90, 37.00 },
{ 37.00, 39.066667, 41.133333, 43.20 },
{ 43.20, 45.466667, 47.733333, 50.00 },
}

which, I suppose, is what you intend.

-- 
Thomas

[And] Re: Wood design program test version [1377 days 21 hours and 46 minutes ago]

Tue, 5 Jul 2022 07:55:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Exactly. The issue here is whether the 'comma' represents a 'Thousands
> separator' (example: 3,943,200.00) or - and I guess this is what is
> intended here - the 'decimal dot' (example: 3943200,00). Neither can be
> used by POV-Ray.
>

>
> As far as I understand this issue, the use of 'thousands separators' is
> only a visually attractive(?) trick, while calculations on those numbers
> ignore them (obviously). My advice would be to drop them altogether,
> especially for input to POV-Ray.
>
> --
> Thomas

What the length unit does you use? Because my outputting number is usually small
with this program(while meter is the length unit).

[And] Re: Wood design program test version [1377 days 22 hours and 6 minutes ago]

Tue, 5 Jul 2022 07:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
> > > However, one very important thing is the way decimals are written to the
> > > example include files. My system uses 'dots' (example: 3.9432) instead
> > > of 'commas' (example: 3,9432) like is done by your app. I guess that
> > > some countries/systems do so standard, but not all.
> >
> > I use 'meter' as the length unit, so that output result is caused by my habit.
> > The dots are decimal points.
>
> Units don't appear to be the issue.   The representation of decimal fractions is
> what Thomas is concerned about.
>

Labeling titles and units on diagram is important I know. I will label them.


> > I want to ask a question, a number contain commas can be read as 'one' number
> > correct by POV-Ray?
> > Can 3,9432 be a number?
>
> Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
> and the "+,-, and ." glyphs to represent numerical values.  Formatting those
> values using str and probably a macro would be necessary to show the usual
> commas between every step of 10^3.
>
>
> > > If this is an issue for better international use, could you make
> > > this an initial choice to make by the user? Or is there another way to
> > > change this easily?
> > >
> > > --
> > > Thomas
> >
>
> I think he means "Is there a way to specify whether to use "," or "." for the
> data's output format.


I'm not clear this time. POV-Ray cannot use a number contains commas as you
said, why I need add commas between every step of 10^3. I attach a picture, this
picture is what I saw on my output data. Is the same format on your output data?

[Thomas de Groot] Re: Wood design program test version [1377 days 23 hours and 4 minutes ago]

Tue, 5 Jul 2022 06:37:36 GMT

Op 04/07/2022 om 20:53 schreef Bald Eagle:
> "And" <49341109@ntnu.edu.tw> wrote:
> 
>>> However, one very important thing is the way decimals are written to the
>>> example include files. My system uses 'dots' (example: 3.9432) instead
>>> of 'commas' (example: 3,9432) like is done by your app. I guess that
>>> some countries/systems do so standard, but not all.
>>
>> I use 'meter' as the length unit, so that output result is caused by my habit.
>> The dots are decimal points.
> 
> Units don't appear to be the issue.   The representation of decimal fractions is
> what Thomas is concerned about.
> 
Exactly. The issue here is whether the 'comma' represents a 'Thousands 
separator' (example: 3,943,200.00) or - and I guess this is what is 
intended here - the 'decimal dot' (example: 3943200,00). Neither can be 
used by POV-Ray.

>> I want to ask a question, a number contain commas can be read as 'one' number
>> correct by POV-Ray?
>> Can 3,9432 be a number?
> 
> Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
> and the "+,-, and ." glyphs to represent numerical values.  Formatting those
> values using str and probably a macro would be necessary to show the usual
> commas between every step of 10^3.
> 
> 
>>> If this is an issue for better international use, could you make
>>> this an initial choice to make by the user? Or is there another way to
>>> change this easily?
>>>
>>> --
>>> Thomas
>>
>> Currently You might need use 'scale' to the pigment to convert it to your
>> customary unit. I will add a list(menu) to select unit on the "Basic
>> Profile"(first page) in the future version. But I need time to research this.
> 
> I think he means "Is there a way to specify whether to use "," or "." for the
> data's output format.
> 

As far as I understand this issue, the use of 'thousands separators' is 
only a visually attractive(?) trick, while calculations on those numbers 
ignore them (obviously). My advice would be to drop them altogether, 
especially for input to POV-Ray.

-- 
Thomas

[Bald Eagle] Re: Wood design program test version [1378 days 10 hours and 46 minutes ago]

Mon, 4 Jul 2022 18:55:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

> > However, one very important thing is the way decimals are written to the
> > example include files. My system uses 'dots' (example: 3.9432) instead
> > of 'commas' (example: 3,9432) like is done by your app. I guess that
> > some countries/systems do so standard, but not all.
>
> I use 'meter' as the length unit, so that output result is caused by my habit.
> The dots are decimal points.

Units don't appear to be the issue.   The representation of decimal fractions is
what Thomas is concerned about.

> I want to ask a question, a number contain commas can be read as 'one' number
> correct by POV-Ray?
> Can 3,9432 be a number?

Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
and the "+,-, and ." glyphs to represent numerical values.  Formatting those
values using str and probably a macro would be necessary to show the usual
commas between every step of 10^3.

> > If this is an issue for better international use, could you make
> > this an initial choice to make by the user? Or is there another way to
> > change this easily?
> >
> > --
> > Thomas
>
> Currently You might need use 'scale' to the pigment to convert it to your
> customary unit. I will add a list(menu) to select unit on the "Basic
> Profile"(first page) in the future version. But I need time to research this.

I think he means "Is there a way to specify whether to use "," or "." for the
data's output format.

[And] Re: Wood design program test version [1378 days 12 hours and 51 minutes ago]

Mon, 4 Jul 2022 16:50:00 GMT

Excuse me, I upload the same version but compress to the .zip

[And] Re: Wood design program test version [1378 days 13 hours and 11 minutes ago]

Mon, 4 Jul 2022 16:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 27-6-2022 om 17:56 schreef And:
> > First release.
>
> Thanks And!
>
> Test version, so I shall not (yet) comment on the visual aspects and so on.
>

Thanks for understanding.

> However, one very important thing is the way decimals are written to the
> example include files. My system uses 'dots' (example: 3.9432) instead
> of 'commas' (example: 3,9432) like is done by your app. I guess that
> some countries/systems do so standard, but not all.

I use 'meter' as the length unit, so that output result is caused by my habit.
The dots are decimal points.
I want to ask a question, a number contain commas can be read as 'one' number
correct by POV-Ray?
Can 3,9432 be a number?

> If this is an issue for better international use, could you make
> this an initial choice to make by the user? Or is there another way to
> change this easily?
>
> --
> Thomas

Currently You might need use 'scale' to the pigment to convert it to your
customary unit. I will add a list(menu) to select unit on the "Basic
Profile"(first page) in the future version. But I need time to research this.

[Thomas de Groot] Re: Wood design program test version [1378 days 17 hours and 35 minutes ago]

Mon, 4 Jul 2022 12:06:39 GMT

Op 27-6-2022 om 17:56 schreef And:
> First release.

Thanks And!

Test version, so I shall not (yet) comment on the visual aspects and so on.

However, one very important thing is the way decimals are written to the 
example include files. My system uses 'dots' (example: 3.9432) instead 
of 'commas' (example: 3,9432) like is done by your app. I guess that 
some countries/systems do so standard, but not all. My system uses 
'dots'. If this is an issue for better international use, could you make 
this an initial choice to make by the user? Or is there another way to 
change this easily?

-- 
Thomas

[And] Re: Wood design program test version [1379 days 22 hours and 6 minutes ago]

Sun, 3 Jul 2022 07:35:00 GMT

The Java version which I used is Java SE 8 (1.8.0_91) currently. So the version
above it should be acceptable.

[And] Re: Wood design program test version [1381 days 16 hours and 26 minutes ago]

Fri, 1 Jul 2022 13:15:00 GMT

Such design is assumed the ideal situation. In fact, I'm planning to revise it.

It is obvious imperfect along the h-direct, When I ..'veneer' it, it shows no
change pattern (along theta).

[And] Re: Wood design program test version [1381 days 16 hours and 46 minutes ago]

Fri, 1 Jul 2022 12:55:00 GMT

'first_time', 'last_time', 'd_boundary_time0', 'd_boundary_time1' define the
boundaries of the pattern on 'time value', you can regarded it as the radial
direct pattern.

't_radial_bump_size' as in attachment picture, unit is year.

'time_node_amount' is because, if it generate only one continuous pattern on
theta, the 'bump_size_along_theta' cannot maintain, the bump_size will get
smaller at the smaller radius. So I generate several patterns. On different
radius, I apply different seg_amount to theta position array[seg_amount]
It is the origin of it needing 'time_node_amount' to determine the amount of
such pattern on different radius. You can set it 3~5 it should sufficient.

[And] Re: Wood design program test version [1381 days 17 hours and 11 minutes ago]

Fri, 1 Jul 2022 12:30:00 GMT

The 'macro' which I should introduce is
generate_thin_circled_pattern_f_input_t_theta_h(
first_time, last_time, d_boundary_time0, d_boundary_time1, t_radial_bump_size,
time_node_amount,
bump_size_along_theta, theta_pos_random_factor,
min_h, max_h, d_boundary_h0, d_boundary_h1,
seed_m,
r_vs_t, h_vs_r_ratio
)

It is located at bump_pattern_base_function_macros.inc

The goal of it is to generate thin pattern, just like f_bumps(x,y,z).
But it is on the different coordinate system(I say that 'tree log coordinate' in
this case), this macro just generate an output_f = function(time, theta, h) {
....
}



It generate bumps along theta by generating an position array[seg_amount] during
0~2*pi, it consult the input 'bump_size_along_theta' to determine the
seg_amount, the shorter the bump size, the larger the seg_amount.

'theta_pos_random_factor' controls the randomize of the positions. When it is
zero, the position is equally spaced on theta, when it is 1, the position has
the max randomize.

[And] Re: Wood design program test version [1384 days 15 hours and 26 minutes ago]

Tue, 28 Jun 2022 14:15:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> this looks like it's going to be a fun tool !

Thomas de Groot <tho### [at] degrootorg> wrote:
> Thank you very much indeed. I am truly impressed. As Maurice said: this
> is going to be fun to play with. I shall let you know my thoughts while
> testing this.
>
> --
> Thomas


Thanks two... 'fun' . ..

[And] Re: Wood design program test version [1384 days 15 hours and 26 minutes ago]

Tue, 28 Jun 2022 14:15:00 GMT

"tree_colormap_temp_file.inc" is the place I composite (all) patterns, ... to
the output pigment.
I directly copy this file from ...which made by myself.
Output pigment is named 'diffuse_pigment'. It has rgb colors. In the future it
is necessary to produce grayscale output for the roughness map, normal map...,
too.

"..._bumps_pattern_detail.inc" prepares the thin pattern, fiber, ... for the
"tree_colormap_temp_file.inc"

You can produce more thin pattern here, using the macro I write
generate_thin_circled_pattern_f_input_t_theta_h(
....
), I only finish this one(in fact two or three, but they appointed by this one)
for generate thin pattern.

You can use any function produced by yourself.

You can change these files above.

[And] Re: Wood design program test version [1384 days 15 hours and 46 minutes ago]

Tue, 28 Jun 2022 13:55:00 GMT

"..._angular_distortion_(0, 1, 2).inc"
connects the angular shape. The more characteristic heights you set, the more
files are produced.
Then
"..._angular_shape_factor.inc"
assemble them.

"..._radial_speed".

The files above is no need to change, if you have thoughts about them, you
should tell me. Because using program to generate these data is more convenient
than DIY.



"..._time_and_ring"
This file composite the radial speed, angular shape distortion,(and knot shape
distortion in the future) to a single function "time_function(x,y,z)", it input
position, output 'age at that position', but in fact :P, its output is zero at
the tree base <0,0,0>, and get bigger when you keep away from the (tree)center.
The Unit is year.

Here it produce two additional function 'pinstripes' and 'wood band', these two
functions output value 0~1, 0 represent early-wood, 1 represent late-wood(dark
part).

[And] Re: Wood design program test version [1384 days 16 hours and 11 minutes ago]

Tue, 28 Jun 2022 13:30:00 GMT

I must introduce these output files. Because I need your participation on the
composite of the patterns.
Although I leave only one (show tree function.pov) to let you tried to render
the example, but I know many people here have the ability to modify something
source ....inc.

[Thomas de Groot] Re: Wood design program test version [1384 days 17 hours and 53 minutes ago]

Tue, 28 Jun 2022 11:48:10 GMT

Op 28-6-2022 om 10:38 schreef And:
> "Preview And Output"
> 
> I do not prepare a file chooser, so you can only change the file name. The
> produced folder located at the folder of the program. You can render the example
> (show tree function.pov) in it.
> 
> You can change the output files yourself, too. I will introduce the output files
> later.

Thank you very much indeed. I am truly impressed. As Maurice said: this 
is going to be fun to play with. I shall let you know my thoughts while 
testing this.

-- 
Thomas

[Mr] Re: Wood design program test version [1384 days 18 hours and 11 minutes ago]

Tue, 28 Jun 2022 11:30:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> "Preview And Output"
>
> I do not prepare a file chooser, so you can only change the file name. The
> produced folder located at the folder of the program. You can render the example
> (show tree function.pov) in it.
>
> You can change the output files yourself, too. I will introduce the output files
> later.

this looks like it's going to be a fun tool !

[And] Re: Wood design program test version [1384 days 21 hours and 1 minute ago]

Tue, 28 Jun 2022 08:40:00 GMT

"Preview And Output"

I do not prepare a file chooser, so you can only change the file name. The
produced folder located at the folder of the program. You can render the example
(show tree function.pov) in it.

You can change the output files yourself, too. I will introduce the output files
later.

[And] Re: Wood design program test version [1384 days 21 hours and 6 minutes ago]

Tue, 28 Jun 2022 08:35:00 GMT

"Edit Angular Shape" can change the shape of the woodgrain. It use polar
coordinate. In fact it control a series of value(default value = 1). When you
drag a control node to make a larger radius, it make the value > 1; when you
drag a control node to make a smaller radius, it make the value < 1.

These three curves located at r = 0.266..m, r = 0.533..m, r = 0.8m.

This is an approximate method. The output result should be accurate when you
just adjust the shape slightly. But if you distort the shape overly the result
will be unpredictable.

[And] Re: Wood design program test version [1384 days 21 hours and 31 minutes ago]

Tue, 28 Jun 2022 08:10:00 GMT

"Edit Radial Grow Speed" change the woodgrain density. The default value is
0.02m/year. If you do not change any control node on it, it will produce annual
ring interval 2cm

(assumed POV-Ray 1 unit = 1 meter)

[And] Re: Wood design program test version [1384 days 22 hours and 16 minutes ago]

Tue, 28 Jun 2022 07:25:00 GMT

Open the program "Wood_Design.jar" in the folder.
It opens this menu.

Click "Edit Basic Profile", fills in the form, when you finish it, click"OK".
Click "Edit Radial Grow Speed", ...
complete the editing sequentially.

The function of output files is just render a block. It is shabby but you can
change the object however.

[And] Re: Wood design program test version [1384 days 22 hours and 26 minutes ago]

Tue, 28 Jun 2022 07:15:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> First release.

Java Runtime Environment can be downloaded here: (Java SE)
https://www.oracle.com/java/technologies/downloads/


I'm looking the OpenJDK, too . . .
Maybe OpenJDK is a better selection.

[And] Wood design program test version [1385 days 13 hours and 41 minutes ago]

Mon, 27 Jun 2022 16:00:00 GMT

First release.

[And] Re: Wood program but still develop [1385 days 20 hours and 26 minutes ago]

Mon, 27 Jun 2022 09:15:00 GMT

I will release a test version on the following day.
(.jar) Executable jar file

I will describe its limit.

[And] Re: Wood program but still develop [1397 days 18 hours and 1 minute ago]

Wed, 15 Jun 2022 11:40:00 GMT

I have completed most of the arrangement of output .inc files.
All effects remains the previous.
In fact, I doubt about the albedo of the (selected) color.

1). I knows that the albedo of many substances are between 0.0.. ~ 0.6...(60%),
the white wall or white paper is just about 60%. The correct value of the albedo
cannot measure from the photograph directly, unless you know the light source
strength.

2). The rendered image shows the current composite of patterns. Include the
fiber and big color block. It takes 20m46s to render.

3). I have fixed and eliminated the discontinuous line on the angle terminal
position.

4). The variance of the pattern is not enough for the z(height) direct. If you
cut this pattern using a cylinder, or just the "rotary peeled" method. The
result pattern will very unnatural.

[And] Re: Wood program but still develop [1401 days 21 hours and 1 minute ago]

Sat, 11 Jun 2022 08:40:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Thank you.
> I like this admix, too.

I imitate that box color and direct of pattern by this one (But the color is
selected by photos of mine) which the texture is scanned.

https://www.turbosquid.com/3d-models/scanned-objects-3d-model-1694388

There are too many details to imitate, but the color changing at the corner is
catch my eye. I know that proximity pattern discussed in the newsgroups.

http://news.povray.org/povray.binaries.images/thread/%3Cweb.4bda394e8fe449e421619a220%40news.povray.org%3E/

[And] Re: Wood program but still develop [1406 days 21 hours and 46 minutes ago]

Mon, 6 Jun 2022 07:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "And" <49341109@ntnu.edu.tw> wrote:
> > ...
> > After investigate colors from photo. put them together reluctantly.
>
> glad you did.  the pattern looks sumptuous, in particular I'm impressed by just
> how believable the texture looks, the graining on the narrow side of the lid is
> ... wow.
>
>
> regards, jr.

Thank you.
I like this admix, too.

[jr] Re: Wood program but still develop [1407 days 21 hours and 1 minute ago]

Sun, 5 Jun 2022 08:40:00 GMT

hi,

"And" <49341109@ntnu.edu.tw> wrote:
> ...
> After investigate colors from photo. put them together reluctantly.

glad you did.  the pattern looks sumptuous, in particular I'm impressed by just
how believable the texture looks, the graining on the narrow side of the lid is
... wow.

regards, jr.

[And] Re: Wood program but still develop [1408 days 12 hours and 36 minutes ago]

Sat, 4 Jun 2022 17:05:00 GMT

Today I searched some procedural wood texture generator on the web, I never got
( maybe I did not concentrate enough) such a program before.

I found two this time.

https://www.blendernation.com/2019/08/08/timber-a-realistic-procedural-pbr-wood-material/

https://blendermarket.com/products/carvature


At the beginning of design my program, I choosed a simple and feasible compage
for it. After adjusting the result texture attentively, I found it can also
accomplish the level. That tempted me to put it into a commercial, too. But
developing software is such a huge affair, I know I will release it in the form
of freeware( maybe alpha or beta test version) before it have the basic
quality(like open/save, or select colors in the gui program).

I'm looking forward PayPal (for the 3D models selling), it will be a new
experience for me at least.

Before release the program, I must learn to prepare something first, and learn
to  compile it.

[And] Re: Wood program but still develop [1409 days 17 hours and 11 minutes ago]

Fri, 3 Jun 2022 12:30:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "And" <49341109@ntnu.edu.tw> wrote:
> > ...
> > Now I know it does not finish yet.
>
> do you always do "blocks", or have you put the texture to use yet?  (thinking,
> eg, the distribution 'woodbox.pov' scene, or such)
>
>
> regards, jr.

After investigate colors from photo. put them together reluctantly.
I apply this yellow color wood to woodbox.pov, only the container.

[And] Re: Wood program but still develop [1416 days 13 hours and 56 minutes ago]

Fri, 27 May 2022 15:45:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Different approach...maybe. Totally the concept, it is about... I draw the
> standard concentric circles(internal wood pattern) there, but I change the input
> coordinate (x, y, z) to (x/factor(..), y/factor(..), z), than it distortion the
> original space on x-y plane direction.
>
> The knot is the same. I distortion the pattern shape in a narrow range, (vs r
> theta and z)





#declare knot_theta_pos = 0.24*pi;
#declare knot_range = 0.41*pi; // 0.28*pi
#declare knot_h_pos = 1.36;

// simple temp r, not a formal one
#declare f_r_vs_t =
function(var_t, h) {
0.03* var_t
}




// r_of_it means the distant of p to the knot(stem) center line.
// but only approximate.
#declare f_knot_about =
function(var_t, r_of_it) {
select(
    r_of_it - knot_range/2,
    (f_r_vs_t(var_t, 0) +0.001*(cos(r_of_it*2*pi/knot_range) +
1)/2/pow(abs(r_of_it), 1.5)  )/f_r_vs_t(var_t, 0),
    1
)
}

#declare f_knot =
function(x, y, z) {
f_knot_about(time_mockup_function(x, y, z), sqrt(pow(f_theta(x,y) -
knot_theta_pos, 2) + pow((z - knot_h_pos)/f_r(x, y, z), 2)) )
}

// -----------------------------------------
#declare time_mockup_with_knot_function =
function (x, y ,z){
time_mockup_function(
x/f_knot(x, y, z),
y/f_knot(x, y, z),
z
)
}

[And] Re: Wood program but still develop [1416 days 14 hours and 21 minutes ago]

Fri, 27 May 2022 15:20:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> This is entering crazy good level realm ! :-)

Thank you.

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 26/05/2022 om 13:42 schreef And:
> > Modify it with rather casual, I need 2-3 weeks to arrange the output .inc files.
> >
> > The knot is an experimental feature.
> > In fact, I'm not clear on how these knot pattern form in photographs.
> >
> Well, as knots are cross-sections of branches at different angles, you
> can consider them identical to the main cross-section of the trunk wood.
> Your attempt is very convincing, although - I suppose - your approach to
> generate them is different.
>
> --
> Thomas

Different approach...maybe. Totally the concept, it is about... I draw the
standard concentric circles(internal wood pattern) there, but I change the input
coordinate (x, y, z) to (x/factor(..), y/factor(..), z), than it distortion the
original space on x-y plane direction.

The knot is the same. I distortion the pattern shape in a narrow range, (vs r
theta and z)

[Thomas de Groot] Re: Wood program but still develop [1416 days 23 hours and 12 minutes ago]

Fri, 27 May 2022 06:29:24 GMT

Op 26/05/2022 om 13:42 schreef And:
> Modify it with rather casual, I need 2-3 weeks to arrange the output .inc files.
> 
> The knot is an experimental feature.
> In fact, I'm not clear on how these knot pattern form in photographs.
> 
Well, as knots are cross-sections of branches at different angles, you 
can consider them identical to the main cross-section of the trunk wood. 
Your attempt is very convincing, although - I suppose - your approach to 
generate them is different.

-- 
Thomas

[Mr] Re: Wood program but still develop [1417 days 14 hours and 26 minutes ago]

Thu, 26 May 2022 15:15:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Modify it with rather casual, I need 2-3 weeks to arrange the output .inc files.
>
> The knot is an experimental feature.
> In fact, I'm not clear on how these knot pattern form in photographs.

This is entering crazy good level realm ! :-)

[And] Re: Wood program but still develop [1417 days 17 hours and 56 minutes ago]

Thu, 26 May 2022 11:45:00 GMT

Modify it with rather casual, I need 2-3 weeks to arrange the output .inc files.

The knot is an experimental feature.
In fact, I'm not clear on how these knot pattern form in photographs.

[Thomas de Groot] Re: Wood program but still develop [1417 days 23 hours and 32 minutes ago]

Thu, 26 May 2022 06:09:02 GMT

Op 25/05/2022 om 17:32 schreef And:
> First experiment to apply knot distortion to the base shape.
> 
> Very experimental trying. potentiality...?

Oh yes! This looks very knot-like, so to speak. You are on the right 
track indeed.

-- 
Thomas

[And] Re: Wood program but still develop [1418 days 13 hours and 6 minutes ago]

Wed, 25 May 2022 16:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "And" <49341109@ntnu.edu.tw> wrote:
> > ...
> > Now I know it does not finish yet.
>
> do you always do "blocks", or have you put the texture to use yet?  (thinking,
> eg, the distribution 'woodbox.pov' scene, or such)
>
>
> regards, jr.

"Now I know it does not finish yet." with this sentence I mean that I cannot
adjust the texture easily. The program outputs the texture result(only shape
distortion detail) --> color apply...to what I want, is semi-automatic.

I did not apply it to 3D models yet. But I know it certainly can apply.
I have tried mesh camera of POV-Ray.

This image is what I want to attach the material. I have made several models,
and I want to sell them on TurboSquid to rescue my poor situation: never
accomplish important things, no income for a long time, ...

I will share the program here in the form of freeware(Not open source), this is
because the program is the first usable one which I develop (To myself
mainly), and it highly dependent on POV-Ray, I know I do not on the step
developing commercial program yet, I need some feedback so.

[And] Re: Wood program but still develop [1418 days 14 hours and 6 minutes ago]

Wed, 25 May 2022 15:35:00 GMT

First experiment to apply knot distortion to the base shape.

Very experimental trying. potentiality...?

[jr] Re: Wood program but still develop [1418 days 14 hours and 41 minutes ago]

Wed, 25 May 2022 15:00:00 GMT

hi,

"And" <49341109@ntnu.edu.tw> wrote:
> ...
> Now I know it does not finish yet.

do you always do "blocks", or have you put the texture to use yet?  (thinking,
eg, the distribution 'woodbox.pov' scene, or such)


regards, jr.

[And] Re: Wood program but still develop [1419 days 15 hours and 11 minutes ago]

Tue, 24 May 2022 14:30:00 GMT

With a very similar setting, whole box, I redraw the shape. There is an artifact
line...,
Now I know it does not finish yet.

My personal purpose is output the UV-map for some mesh 3D model, I modeling them
in Blender now.

[And] Re: Wood program but still develop [1419 days 15 hours and 31 minutes ago]

Tue, 24 May 2022 14:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
> > This picture take 18m47s render time, It will slow down when combine more
> > (layer, concept)s.
>
> That seems like a very long time for such a simple render.  I would imagine that
> you can get a similar result a lot faster if the troubles were identified and
> optimised.  I like to consult Inigo Quilez, and Martijn Steinrucker (Art of
> Code), since their approach to computer graphics is very different, and forces
> me to consider different approaches and ways to simplify and optimize any
> function-based code I'm interested in writing.
Thank you. I never develop my (not chinese)social circle besides news.povray.
Maybe I can try someday.

And, that rendered picture is a 3D one, not a pattern. It turn on radiosity and
rendered using my notebook, so I'm not suspect this situation too much.



> TOK always has a way of slicing through a lot of these problems like a laser,
> but I think it's very educational to explore a number of approaches before
> others offer up solutions of their own.
>
> > And my main method is distinguish the heartwood, inner-sapwood, mid-sapwood,
> > outer-sapwood..., this one I only detail the mid-sapwood.
>
> As slow as it is, I think that middle layer is looking great, and your progress
> in this project is definitely showing incremental successes!  :)

Thanks.

[Bald Eagle] Re: Wood program but still develop [1419 days 18 hours and 46 minutes ago]

Tue, 24 May 2022 10:55:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

> This picture take 18m47s render time, It will slow down when combine more
> (layer, concept)s.

That seems like a very long time for such a simple render.  I would imagine that
you can get a similar result a lot faster if the troubles were identified and
optimised.  I like to consult Inigo Quilez, and Martijn Steinrucker (Art of
Code), since their approach to computer graphics is very different, and forces
me to consider different approaches and ways to simplify and optimize any
function-based code I'm interested in writing.
TOK always has a way of slicing through a lot of these problems like a laser,
but I think it's very educational to explore a number of approaches before
others offer up solutions of their own.

> And my main method is distinguish the heartwood, inner-sapwood, mid-sapwood,
> outer-sapwood..., this one I only detail the mid-sapwood.

As slow as it is, I think that middle layer is looking great, and your progress
in this project is definitely showing incremental successes!  :)

[And] Re: Wood program but still develop [1419 days 20 hours and 36 minutes ago]

Tue, 24 May 2022 09:05:00 GMT

Composite pigment_map and functions is more cumbersome than I think. I only
treat preconceived it easy.

The earlywood color and merge effect is not bad, but maybe strange at latewood.
Not know, should look the side cross section,  but for the purpose of trying the
pigment/color_map as quickly, I don't fix that varying function (vs height) yet.

This picture take 18m47s render time, It will slow down when combine more
(layer, concept)s.
And my main method is distinguish the heartwood, inner-sapwood, mid-sapwood,
outer-sapwood..., this one I only detail the mid-sapwood.

[And] Re: Wood program but still develop [1426 days 16 hours and 21 minutes ago]

Tue, 17 May 2022 13:20:00 GMT

Before continue the pigment_map and color, I tried a incredible detail idea
yesterday that I thought recently. Can be a new target to complete in the
future.

It is the knot.
But I'm willing to develop this feature with not so accurate shape only, I'd
like to implement it with (as much as possible) simple mathematical formula.


https://www.researchgate.net/figure/Longitudinal-section-through-a-tree-trunk-and-branch-Mueller-et-al-2006_fig1_274618
751

[And] Re: Wood program but still develop [1427 days 16 hours and 21 minutes ago]

Mon, 16 May 2022 13:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> When you abrade wood, erode it - like with driftwood, or stain it, you get an
> enhancement of the grain.  This is due to the alternating hard/soft regions, and
> usually the soft regions are light, and the harder regions are more brown.

Thanks for this knowledge.

>
> > > Holes due to boring insects
> > > "checking" (cracks) due to splitting when cut wood is rapidly dried
> >
> > Are you a professional person? Maybe we can discuss it. I don't know so much
> > about it.
>
> I don't do anything with wood for a living, but I've felled, sawn, and worked
> with lots of different wood.  And made plenty of mistakes.

Here is no chance to fell a tree, not to mention I'm living in a city. Such a
thing is secluded to me, so I have respect to the people who can do these
things.

> > > Then there's the fun of formulating pigment/texture maps for all of the
> > > different species...  ;)

That's right, I will use pigment_map, but this is a picture I rendered, improved
the defect yesterday, and this is a two layered(in fact average of two) pattern
with different fiber length, eliminate some artifact about the coherence.

[And] Re: Wood program but still develop [1428 days 14 hours and 41 minutes ago]

Sun, 15 May 2022 15:00:00 GMT

I'm satisfied with this one, but with heavier coverage it is not so natural.
And variety for the height is a problem (I cancelled the original form, the new
one is list-to-do).

I found pigment_map should be a better method to composite the base color with
the thin fiber. Thus the fiber can be a darker color than the base. I still use
the 'average', but I will rewrite it.


If the output pigment want to maintain the fiber length, wood heart is another
challenge, I have tried some method, but no perfect one.

[And] Re: Wood program but still develop [1428 days 15 hours and 16 minutes ago]

Sun, 15 May 2022 14:25:00 GMT

And this one about 0.01m.

With some artifact during the position it shows staggered.
I should think a better method.

[And] Re: Wood program but still develop [1428 days 15 hours and 21 minutes ago]

Sun, 15 May 2022 14:20:00 GMT

Browse your links roughly. Thank you.
Careless reading because I still effort on existed plane.


This one I cancelled the vertical pattern because it looks artifact.
And I try using several pattern (vs different age) superposition , because I
would like maintain the fiber length at different position.

This one about 0.1m.

[Bald Eagle] Re: Wood program but still develop [1429 days 7 hours and 11 minutes ago]

Sat, 14 May 2022 22:30:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > Alternating light-dark / thick-thin growth rings
>
> I'm not sure. Is this the previous item I reply but I interpret your meaning
> wrong?

I think there are several aspects of tree rings that are all sort of
interrelated.

https://www.theforestacademy.com/tree-knowledge/annual-growth-rings/

When you abrade wood, erode it - like with driftwood, or stain it, you get an
enhancement of the grain.  This is due to the alternating hard/soft regions, and
usually the soft regions are light, and the harder regions are more brown.
Maybe xylem and phloem?

> > Holes due to boring insects
> > "checking" (cracks) due to splitting when cut wood is rapidly dried
>
> Are you a professional person? Maybe we can discuss it. I don't know so much
> about it.

I don't do anything with wood for a living, but I've felled, sawn, and worked
with lots of different wood.  And made plenty of mistakes.

https://blog.spib.org/shakes-checks-and-splits-in-dimension-lumber/

https://thetoolscout.com/how-to-dry-wood-fast-for-woodworking/

> > Then there's the fun of formulating pigment/texture maps for all of the
> > different species...  ;)
>
> My living country don't have much ... oak, pine ..., which species I see in the
> book. (Not the same)
> I'm not very familiar with these.

Thankfully there are now millions of images that you can search to see what any
types of wood look like, and all of the variations and defects, some of whick
are highly sought after - liked spalted wood.

[Bald Eagle] Re: Wood program but still develop [1429 days 7 hours and 21 minutes ago]

Sat, 14 May 2022 22:20:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

> > Asymmetric growth ring thickness. (a bent or curved branch will be thick on one
> > side and thin on the other)
>
> Not uniform ring thickness I wonder how to implement. Basically, if it can
> implement in POV-Ray, than it can do in principle. My Java program can output
> some data and it can be numerous like the attachment.

You could just an angle value to multiply the radius or thickness by.
use atan2, and make sure the output of the function varies from 0 to 1 from one
side of the unit circle to the other.  then multioply by some amount of bend and
then add 1, to get a range from 1 to N.

If you know how to do things like geometric inversion, you could use that to
distort the cylinder like a torus is distorted into a Dupin cylide.

There may be other ways as well.

[And] Re: Wood program but still develop [1429 days 22 hours and 26 minutes ago]

Sat, 14 May 2022 07:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Alternating light-dark / thick-thin growth rings

I'm not sure. Is this the previous item I reply but I interpret your meaning
wrong?

> Darkening along a localized group of rings due to mold/fungus, etc.

I think it shoud contain this, too. But wait until I solve every situation I
encounter.

> Holes due to boring insects
> "checking" (cracks) due to splitting when cut wood is rapidly dried

Are you a professional person? Maybe we can discuss it. I don't know so much
about it.

> a more granular texture for the rings to represent the fibrous nature of the
> wood.

It will be competent, I'm thinking how to do this, too.

> SSLT

I'm not make efforts for the POV-Ray render. I only do the texture in POV-Ray
than I want to output the (maybe UV-map) image to another program. It can form
the pigment, ... at least.

>
> Diagrams or photos of wood would likely help you envision the types of functions
> that would control each of those attributes, and suggest ways to combine them
> into a final overall texture/material.

> There are all of the different ways to cut wood to get different grain patterns
> and expansion/contraction behaviour.

I need realize this, too.

>
> Then there's the fun of formulating pigment/texture maps for all of the
> different species...  ;)

My living country don't have much ... oak, pine ..., which species I see in the
book. (Not the same)
I'm not very familiar with these.

[And] Re: Wood program but still develop [1429 days 23 hours and 6 minutes ago]

Sat, 14 May 2022 06:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
> > Thanks. I'm trying to generate small speckles.
> >
> > It is an emphasis, too.
> >
> > And I'm thinking how composite this to the base color. I use "average" in this
> > picture. But this method is fail to more requirements. Sometimes speckles should
> > darker than the base color. the method cannot control it well.
>
> I think that this is going to be another advanced-granite texture odyssey.
>
> You will probably need to use functions, and some way to introduce noise, in
> order to randomize those color variations in the growth rings.
>

I always use functions, till the pigment composite.

> If you're going to tackle that, I'd probably start by making a list of common
> features of real wood, and think about how to implement each of those, and where
> they need to be in a hierarchy.

Yes, I'm dealing with it.

>
> Different growth ring thicknesses. (one ring vs another)

It has done, notice the program manipulate video 0:12 ~ 0:29, it control the
radial growth speed vs year.
Than program output the year_vs_r function using select(r - r0, , ...),
than composite them to time_function(x, y, z) with angular distortion.

> Variable growth ring thickness (change in thickness along any given ring)

This is a good idea, I think I should add it.

> Asymmetric growth ring thickness. (a bent or curved branch will be thick on one
> side and thin on the other)

Not uniform ring thickness I wonder how to implement. Basically, if it can
implement in POV-Ray, than it can do in principle. My Java program can output
some data and it can be numerous like the attachment.

[Bald Eagle] Re: Wood program but still develop [1430 days 10 hours and 16 minutes ago]

Fri, 13 May 2022 19:25:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:

> Thanks. I'm trying to generate small speckles.
>
> It is an emphasis, too.
>
> And I'm thinking how composite this to the base color. I use "average" in this
> picture. But this method is fail to more requirements. Sometimes speckles should
> darker than the base color. the method cannot control it well.

I think that this is going to be another advanced-granite texture odyssey.

You will probably need to use functions, and some way to introduce noise, in
order to randomize those color variations in the growth rings.

If you're going to tackle that, I'd probably start by making a list of common
features of real wood, and think about how to implement each of those, and where
they need to be in a hierarchy.

Different growth ring thicknesses. (one ring vs another)
Variable growth ring thickness (change in thickness along any given ring)
Asymmetric growth ring thickness. (a bent or curved branch will be thick on one
side and thin on the other)
Alternating light-dark / thick-thin growth rings
Darkening along a localized group of rings due to mold/fungus, etc.
Holes due to boring insects
"checking" (cracks) due to splitting when cut wood is rapidly dried
a more granular texture for the rings to represent the fibrous nature of the
wood.
SSLT

Diagrams or photos of wood would likely help you envision the types of functions
that would control each of those attributes, and suggest ways to combine them
into a final overall texture/material.
There are all of the different ways to cut wood to get different grain patterns
and expansion/contraction behaviour.

Then there's the fun of formulating pigment/texture maps for all of the
different species...  ;)

[And] Re: Wood program but still develop [1430 days 13 hours and 26 minutes ago]

Fri, 13 May 2022 16:15:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > "And" <49341109@ntnu.edu.tw> wrote:
> > > I will post some pictures in the following days. Not very high grade，but
> > > has reached a stage.
> >
> > The basic idea here..
>
> All of these results are awesome !

Thanks. I'm trying to generate small speckles.

It is an emphasis, too.

And I'm thinking how composite this to the base color. I use "average" in this
picture. But this method is fail to more requirements. Sometimes speckles should
darker than the base color. the method cannot control it well.

[Mr] Re: Wood program but still develop [1433 days 17 hours and 26 minutes ago]

Tue, 10 May 2022 12:15:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > I will post some pictures in the following days. Not very high grade，but
> > has reached a stage.
>
> The basic idea here..

All of these results are awesome !

[And] Re: Wood program but still develop [1433 days 20 hours and 16 minutes ago]

Tue, 10 May 2022 09:25:00 GMT

See again this picture.
https://www.pinterest.com/pin/451415562633095644/

with annotate:
https://www.britannica.com/science/growth-ring-plant-anatomy

[And] Re: Wood program but still develop [1434 days 12 hours and 56 minutes ago]

Mon, 9 May 2022 16:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 9-5-2022 om 15:49 schreef And:
> > And the program look.
> >
> > Not very finish. But it can run, and can output file.(.pov and several .inc)
> >
> > Does not contain any color_map edit or design yet. I still code them in Pov-ray
> > and seek a solution for the(more complex) combine.
>
>
> Really impressive indeed. I am following this development with interest.
>
> --
> Thomas

Thank you.

It needs several improve. Some are very basic but don't complete yet.
I will release it here for tests when it is ok(and at least when I learn how to
compile a java project to a executable program, but I should need several
months).

[Thomas de Groot] Re: Wood program but still develop [1434 days 15 hours and 13 minutes ago]

Mon, 9 May 2022 14:28:35 GMT

Op 9-5-2022 om 15:49 schreef And:
> And the program look.
> 
> Not very finish. But it can run, and can output file.(.pov and several .inc)
> 
> Does not contain any color_map edit or design yet. I still code them in Pov-ray
> and seek a solution for the(more complex) combine.


Really impressive indeed. I am following this development with interest.

-- 
Thomas

[And] Re: Wood program but still develop [1434 days 15 hours and 46 minutes ago]

Mon, 9 May 2022 13:55:01 GMT

And the program look.

Not very finish. But it can run, and can output file.(.pov and several .inc)

Does not contain any color_map edit or design yet. I still code them in Pov-ray
and seek a solution for the(more complex) combine.

[And] Re: Wood program but still develop [1434 days 16 hours and 16 minutes ago]

Mon, 9 May 2022 13:25:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> I will post some pictures in the following days. Not very high grade，but
> has reached a stage.

The basic idea here..

[And] Re: Wood program but still develop [1437 days 16 hours and 31 minutes ago]

Fri, 6 May 2022 13:10:00 GMT

I will post some pictures in the following days. Not very high grade，but
has reached a stage.

[And] Re: Wood program but still develop [1557 days 16 hours and 41 minutes ago]

Thu, 6 Jan 2022 13:00:00 GMT

with polar-coordinate.

[And] Re: Wood program but still develop [1557 days 16 hours and 51 minutes ago]

Thu, 6 Jan 2022 12:50:00 GMT

Slow-pace develop but arrive a step.

[And] Re: Wood program but still develop [1615 days 5 hours and 40 minutes ago]

Wed, 10 Nov 2021 00:01:04 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 11/1/2021 2:38 AM, And wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> >>
> >> Hey - this is looking quite promising already.  :)
> >>
> >
> > Oh thanks.
>
> How is it with animations? The thing I hate about the built-in wood
> textures is that they distort wildly when I change the angle of camera
> to wood.
>
> dik

Can you upload a short animation video? I never encounter this situation when I
use the built-in wood texture.

[Dick Balaska] Re: Wood program but still develop [1621 days 6 hours and 58 minutes ago]

Wed, 3 Nov 2021 22:42:55 GMT

On 11/1/2021 2:38 AM, And wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>
>> Hey - this is looking quite promising already.  :)
>>
> 
> Oh thanks.

How is it with animations? The thing I hate about the built-in wood 
textures is that they distort wildly when I change the angle of camera 
to wood.

dik

[And] Re: Wood program but still develop [1621 days 17 hours and 26 minutes ago]

Wed, 3 Nov 2021 12:15:00 GMT

Paolo Gibellini <p.g### [at] gmailcom> wrote:
> Il 01/11/2021 07:38, And ha scritto:
>  > "Bald Eagle" <cre### [at] netscapenet> wrote:
>  >>
>  >> Hey - this is looking quite promising already.  :)
>  >>
>
> Very promising, indeed. It will be a useful tool.
>
> Paolo

Thank you.

I also need to work hard.

[Paolo Gibellini] Re: Wood program but still develop [1623 days 5 hours and 23 minutes ago]

Tue, 2 Nov 2021 00:18:43 GMT

Il 01/11/2021 07:38, And ha scritto:
 > "Bald Eagle" <cre### [at] netscapenet> wrote:
 >>
 >> Hey - this is looking quite promising already.  :)
 >>

Very promising, indeed. It will be a useful tool.

Paolo

[And] Re: Wood program but still develop [1623 days 22 hours and 56 minutes ago]

Mon, 1 Nov 2021 06:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Hey - this is looking quite promising already.  :)
>

Oh thanks.

> Are you using Bezier splines?  What are you going to be using the curve for?
> Controlling the color_map of the wood pigment pattern? The geometry of the wood?
>  Both?

I choose a beautiful picture, so not very clear what it is.
I upload another picture.
I implement it with Bezier spline, but don't allow user to edit the tangent
handle point, instead it generate the tangent handle points automatically, for
maintain every part of the curve is smooth.

Control the shape of annual ring. instead of perfect circle. Like ... this photo
on gallery:
https://www.istockphoto.com/photo/wood-texture-gm175444922-20420677

I start the wood pattern with perfect concentric circles and constant grow
rate(interval of two ring), but it is too inflexible, I want some variety, so I
rewrite it with segmented curve. I don't have too much idea for the color_map
now.

>
> Maybe you can look at Ed Hynan's EPspline lathe/sor editor program for some
> inspiration.
>
> It's really nice that you're writing it in Java - will we be able to try this
> out by running the applet in a web browser?

I never thought that, maybe it can transfer to applet after finish, but I focus
on the program itself currently.

>
>
> My wood pigment patterns have always been fairly simplistic, and I'm sure I can
> learn a lot of things that I should have been doing for a long time now, just by
> seeing the progress of your development renders and relevant scene code.
>
>
> - Bill

Ha ha... that sky render is too big and need too much experiment to improve, I
cannot develop it in this stage. It is far from an one person work.

[Bald Eagle] Re: Wood program but still develop [1624 days 16 hours and 26 minutes ago]

Sun, 31 Oct 2021 13:15:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Because this is such a (suitable size) program that I can develop by myself(one
> person)

Hey - this is looking quite promising already.  :)

Are you using Bezier splines?  What are you going to be using the curve for?
Controlling the color_map of the wood pigment pattern? The geometry of the wood?
 Both?

Maybe you can look at Ed Hynan's EPspline lathe/sor editor program for some
inspiration.

It's really nice that you're writing it in Java - will we be able to try this
out by running the applet in a web browser?

My wood pigment patterns have always been fairly simplistic, and I'm sure I can
learn a lot of things that I should have been doing for a long time now, just by
seeing the progress of your development renders and relevant scene code.

- Bill

[And] Re: Wood program but still develop [1624 days 22 hours and 31 minutes ago]

Sun, 31 Oct 2021 07:10:00 GMT

Because this is such a (suitable size) program that I can develop by myself(one
person)

[And] Re: Wood program but still develop [1625 days 15 hours and 36 minutes ago]

Sat, 30 Oct 2021 14:05:00 GMT

I wrote a curve editor first(video), but need to improve and extend. I feel it
is very challenge to me to develop a good and complete component program.

It's the current situation...

[And] Wood program but still develop [1625 days 15 hours and 56 minutes ago]

Sat, 30 Oct 2021 13:45:00 GMT

I tried to generate some wood pattern last year. But for the purpose of control
the curve, I typed very much code and number(not only the picture shows).

So I decided to write a (java) program. Using mouse to control some basic curve
of the annual rings. Than output a few .pov file to draw the picture(pattern).
But still not finish. Take the advantage of write an appropriate size program I
can practice my coding skill, too.

Because it is prototype, I will release it and take this to make a change...
Maybe will be early next year.

[Thomas de Groot] Re: Domenator, last version [1638 days 17 hours and 54 minutes ago]

Sun, 17 Oct 2021 11:47:42 GMT

Op 17-10-2021 om 12:50 schreef Mediat:
> Here it is
> 

Hi Philippe!

Yes, this is a very acceptable solution indeed. It solves the problem 
quite nicely.

Un grand merci pour ton excellent boulot! :-)

-- 
Thomas

[Mediat] Re: Domenator, last version [1638 days 18 hours and 46 minutes ago]

Sun, 17 Oct 2021 10:55:00 GMT

Here it is

[Mediat] Re: Domenator, last version [1638 days 18 hours and 51 minutes ago]

Sun, 17 Oct 2021 10:50:00 GMT

Hi Thomas,

Here is a non "official" version (I still have a bug that resists) but I'd like
to know if the new way suits you.

I must warn you : do not close the extra windows (Decor and PostProcessing) by
clicking on the upper right X, it would close the program and you could lose
unregistered work, use only the "Quit" button

Best regards

Philippe

[Mediat] Re: Domenator, last version [1640 days 17 hours and 26 minutes ago]

Fri, 15 Oct 2021 12:15:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> freeglut.dll (23-3-2018)
> msvcp140d.dll (19-1-2018)
> ucrtbased.dll (14-8-2016)
> vcruntime140d.dll (23-3-2018)
>
> Somehow, the more recent versions I downloaded a couple of days ago did
> not do the job?!? [beyond my ken]


Hi

Here isDomenator V6, with new features

You can see some of the domes here :

http://news.povray.org/povray.binaries.images/thread/%3Cweb.61696df3c23a6d9e3310c05020ebe1@news.povray.org%3E//povray.b
inaries.images/thread/%3Cweb.61696df3c23a6d9e3310c05020ebe1@news.povray.org%3E/

[Mediat] Re: Domenator, last version [1657 days 15 hours and 36 minutes ago]

Tue, 28 Sep 2021 14:05:00 GMT

I also modified a little the vizualisation of th stuts (Main and Minor)

[Mediat] Re: Domenator, last version [1657 days 15 hours and 36 minutes ago]

Tue, 28 Sep 2021 14:05:00 GMT

and here is the "Snake"

[Mediat] Re: Domenator, last version [1657 days 15 hours and 36 minutes ago]

Tue, 28 Sep 2021 14:05:00 GMT

I added 3 types of decor, the 1st one is the "Spirale", that you can see in my
previous message, here is the 2nd one : the "Frieze"

[Mediat] Re: Domenator, last version [1665 days 19 hours and 11 minutes ago]

Mon, 20 Sep 2021 10:30:00 GMT

Hi

A new feature to come : a new kind of struts

[Mediat] Re: Domenator, last version [1669 days 13 hours and 26 minutes ago]

Thu, 16 Sep 2021 16:15:00 GMT

>
> Oh! Cool!

I'll upload it in a few days (need testing)

[Thomas de Groot] Re: Domenator, last version [1669 days 13 hours and 59 minutes ago]

Thu, 16 Sep 2021 15:42:31 GMT

Op 16-9-2021 om 17:03 schreef Mediat:
> Hi
> 
> Thomas asked me :
>>> Am I right that the obj version only reproduces the dome's "shell"
>>> and not the ribs or struts and such?
> 
> He was right, but now it is possible : the image beyond is a captue of a 3d
> viewer showing a generated OBJ files with the struts, the spheres and the
> colors. Of course, with the 3d viewer you can rotate, translate and zoom in/out
> the object.
> 

Oh! Cool!

-- 
Thomas

[Mediat] Re: Domenator, last version [1669 days 14 hours and 36 minutes ago]

Thu, 16 Sep 2021 15:05:00 GMT

Hi

Thomas asked me :
>>Am I right that the obj version only reproduces the dome's "shell"
>>and not the ribs or struts and such?

He was right, but now it is possible : the image beyond is a captue of a 3d
viewer showing a generated OBJ files with the struts, the spheres and the
colors. Of course, with the 3d viewer you can rotate, translate and zoom in/out
the object.

[Mediat] Re: Domenator, last version [1678 days 19 hours and 11 minutes ago]

Tue, 7 Sep 2021 10:30:00 GMT

Hi

Here is the latest version:

1) Correction of a few little bugs
2) New features (sharpening, which is roughly the opposite of smoothing)

Enjoy

Philippe

[Mediat] Re: Domenator, last version [1684 days 16 hours and 56 minutes ago]

Wed, 1 Sep 2021 12:45:00 GMT

Hi Thomas

>> Am I right that the obj version only
>> reproduces the dome's "shell" and not the ribs or struts and such?

You are right the OBJ and STL files reproduce only the "face" structure, not the
struts


I'm very happy to see to see you got it to work

Best regards

Philippe

[Thomas de Groot] Re: Domenator, last version [1684 days 17 hours and 19 minutes ago]

Wed, 1 Sep 2021 12:22:45 GMT

Yeah! Got the hang of it again! :-)

-- 
Thomas

[Thomas de Groot] Re: Domenator, last version [1684 days 17 hours and 30 minutes ago]

Wed, 1 Sep 2021 12:11:36 GMT

I'll be back a bit later about all this, as I first want to finalise the 
granites macro this week.

Just a question at this stage: Am I right that the obj version only 
reproduces the dome's "shell" and not the ribs or struts and such? That 
is also what I think I remember from the past. I got a saved dom file to 
reload correctly and I got again the knowledge about the inc file's 
structure. I need to get familiarised again with the different scales of 
the dome elements, compared with each other.

-- 
Thomas

[Thomas de Groot] Re: Domenator, last version [1684 days 17 hours and 37 minutes ago]

Wed, 1 Sep 2021 12:04:00 GMT

Op 1-9-2021 om 11:43 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>
>> The best you can do is to put them in the same folder as
>> the application itself. So, my Domenator folder contains:
>>
>> Domenator.exe
>> freeglut.dll
>> msvcp140d.dll
>> ucrtbased.dll
>> vcruntime140d.dll
>>
>> This works fine, except as I said earlier, with the most recent versions
>> of the dll's. I attach a zip with those which work for me as I am not
>> sure how or where you could find those particular versions. I copied
>> them from one of my other folders.
>>
> 
> Thanks! And also for the .dll's. :-) I may give this a try and see what happens.
> I have no idea yet if my Win 10 system has any of those dll's already installed
> in other places (in which case, one version might be used rather than another?)
> But such Windows voodoo is beyond my knowledge.
> 

I have (I noticed) different versions of the same dll's in different 
directories, the flotsam of several years of playing around :-) I never 
experienced any trouble (which doesn't mean anything of course, given my 
illiteracy into the arcane knowledge about our electronic little 
helpers' hard/software).

-- 
Thomas

[Mediat] Re: Domenator, last version [1684 days 19 hours and 41 minutes ago]

Wed, 1 Sep 2021 10:00:00 GMT

Hi Kenneth,

I hope it'll work and you'll enjoy it, if it is the case, feel free to report
any bug or request any feature

Best regards

Philippe

[Kenneth] Re: Domenator, last version [1684 days 19 hours and 56 minutes ago]

Wed, 1 Sep 2021 09:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
>
> The best you can do is to put them in the same folder as
> the application itself. So, my Domenator folder contains:
>
> Domenator.exe
> freeglut.dll
> msvcp140d.dll
> ucrtbased.dll
> vcruntime140d.dll
>
> This works fine, except as I said earlier, with the most recent versions
> of the dll's. I attach a zip with those which work for me as I am not
> sure how or where you could find those particular versions. I copied
> them from one of my other folders.
>

Thanks! And also for the .dll's. :-) I may give this a try and see what happens.
I have no idea yet if my Win 10 system has any of those dll's already installed
in other places (in which case, one version might be used rather than another?)
But such Windows voodoo is beyond my knowledge.

[Mediat] Re: Domenator, last version [1685 days 18 hours and 21 minutes ago]

Tue, 31 Aug 2021 11:20:00 GMT

Hi Thomas,

Here is an image where I used all the 11 possible material and it seems to work

Best regards

Philippe

[Mediat] Re: Domenator, last version [1685 days 19 hours and 16 minutes ago]

Tue, 31 Aug 2021 10:25:00 GMT

Hi Thomas,

> Ah! OK. Confusing indeed, especially as the *.DOM file goes into the
> same directory as the exe.

I'm not prood of this part, but I'm open to suggestion

> Also, saved *.DOM files when loaded again, do not show the originally
> saved object, but a default half sphere.

I never experienced that, can you pack the DOM files in a Zip and I'll have a
look;

> I am confused about the 'Materials'(and the objects). Do I have to use
> the same names as those given in the droplist for WireFrame/Flat Faces/
> Smooth Faces? Whether I do that or not, no materials are exported, nor
> is the geometry subdivided according to different materials. In Poseray,
> I get one unnamed_group (a half sphere) with one unnamed_material
> (white), whatever I do.

You can use any name, the material is not generated, just used, so you must
define the material used before the include


> Hmmm... I am unable to reproduce this...

I noticed no problem, but I will create a "complete" sample

Best regards

Philippe

[Thomas de Groot] Re: Domenator, last version [1685 days 20 hours and 49 minutes ago]

Tue, 31 Aug 2021 08:52:29 GMT

Op 31-8-2021 om 09:37 schreef Mediat:
> 
> Hi Kenneth
> 
> I hope you'll succeed, Thomas has explained the problem and there is nothing I
> can do.
> 
> Enjoy
> 
> Hi Thomas,
> 
> The STL and OBJ Button generate name.STL and name.OBJ files whiche you can read
> in a lot of 3d-viewer (I use glc-viewer), and it should be compatible with 3D
> printers (but I don't have access to any, so I haven't tried)
> The INC button generates the POV file, these 3 files are generated in the
> directory above the one where the exe stands (maybe not a very good idea)
> 
Ah! OK. Confusing indeed, especially as the *.DOM file goes into the 
same directory as the exe.

Also, saved *.DOM files when loaded again, do not show the originally 
saved object, but a default half sphere.

> If you don't declare any material, you will have to declare one in your pov-file
> for the entire union, but you can be more specific :
> 
I am confused about the 'Materials'(and the objects). Do I have to use 
the same names as those given in the droplist for WireFrame/Flat Faces/ 
Smooth Faces? Whether I do that or not, no materials are exported, nor 
is the geometry subdivided according to different materials. In Poseray, 
I get one unnamed_group (a half sphere) with one unnamed_material 
(white), whatever I do.

> 1) Dome material is the same as the pov definition for the entire object
> 2) Face material will affect the mesh part only
> 3) Struts materials, you can define different material for parallel an meridian
> struts, major and minor struts
> 4) Diagonal struts, same thing for the diagonals (usually you don't want to see
> them, but I have an exemple ...)
> 5) Spheres material, usually the same as one of the struts tha the sphere
> completes
> 
Hmmm... I am unable to reproduce this...

> In the image trashbin, the faces are not generated, only the major parallele
> struts have a non 0 radius
> In the franc-contois image (it is a dome I saw in a french xountryside called
> lead material.
> 
Nice ones!

-- 
Thomas

[Mediat] Re: Domenator, last version [1685 days 22 hours and 1 minute ago]

Tue, 31 Aug 2021 07:40:00 GMT

The other file

[Mediat] Re: Domenator, last version [1685 days 22 hours and 1 minute ago]

Tue, 31 Aug 2021 07:40:00 GMT

Hi Kenneth

I hope you'll succeed, Thomas has explained the problem and there is nothing I
can do.

Enjoy

Hi Thomas,

The STL and OBJ Button generate name.STL and name.OBJ files whiche you can read
in a lot of 3d-viewer (I use glc-viewer), and it should be compatible with 3D
printers (but I don't have access to any, so I haven't tried)
The INC button generates the POV file, these 3 files are generated in the
directory above the one where the exe stands (maybe not a very good idea)

If you don't declare any material, you will have to declare one in your pov-file
for the entire union, but you can be more specific :

1) Dome material is the same as the pov definition for the entire object
2) Face material will affect the mesh part only
3) Struts materials, you can define different material for parallel an meridian
struts, major and minor struts
4) Diagonal struts, same thing for the diagonals (usually you don't want to see
them, but I have an exemple ...)
5) Spheres material, usually the same as one of the struts tha the sphere
completes

In the image trashbin, the faces are not generated, only the major parallele
struts have a non 0 radius
In the franc-contois image (it is a dome I saw in a french xountryside called
lead material.

[Thomas de Groot] Re: Domenator, last version [1685 days 23 hours and 6 minutes ago]

Tue, 31 Aug 2021 06:35:23 GMT

Op 30/08/2021 om 18:45 schreef Mediat:
> Computer mysteries ;-))
>
Indeed.

> 
> 
> I'll post the next version in a few days
> 
> Have fun and let me know
> 
> Best regards
> 
> 
A couple of things I have forgotten since earlier versions:

1) how do you save to INC, STL, OBJ? clicking those buttons doesn't do 
anything.

2) How do the different 'Material' options work?

-- 
Thomas

[Thomas de Groot] Re: Domenator, last version [1685 days 23 hours and 26 minutes ago]

Tue, 31 Aug 2021 06:15:06 GMT

Op 30/08/2021 om 19:03 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>
>> Interestingly: I copied the following dll's from the laptop where
>> Domenator /did/ work, to the one where it /didn't/, and Lo! it works
>> now! Go understand.
>>
>> freeglut.dll (23-3-2018)
>> msvcp140d.dll (19-1-2018)
>> ucrtbased.dll (14-8-2016)
>> vcruntime140d.dll (23-3-2018)
>>
>> Somehow, the more recent versions I downloaded a couple of days ago did
>> not do the job?!? [beyond my ken]
>>
> 
> Good to hear!
> 
> I'd like to try the Domenator out as well, but I'm wary of installing .dlls
> (Windows 10). It's "beyond my Ken" too :=P
> 
> Any tips you can give as to where they would go? Or problems to expect?
>

Hi Kenneth!
I am like you. The best you can do is to put them in the same folder as 
the application itself. So, my Domenator folder contains:

Domenator.exe
freeglut.dll
msvcp140d.dll
ucrtbased.dll
vcruntime140d.dll

This works fine, except as I said earlier, with the most recent versions 
of the dll's. I attach a zip with those which work for me as I am not 
sure how or where you could find those particular versions. I copied 
them from one of my other folders.

A tiny drawback of this method might be if you have several folders with 
different applications and all containing copies of the same dll's. That 
happens on my system. However, most dll's are quite small and take 
little space, and I have not been aware of any interference. But more 
knowledgeable people might know.

-- 
Thomas

[Kenneth] Re: Domenator, last version [1686 days 12 hours and 36 minutes ago]

Mon, 30 Aug 2021 17:05:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> Interestingly: I copied the following dll's from the laptop where
> Domenator /did/ work, to the one where it /didn't/, and Lo! it works
> now! Go understand.
>
> freeglut.dll (23-3-2018)
> msvcp140d.dll (19-1-2018)
> ucrtbased.dll (14-8-2016)
> vcruntime140d.dll (23-3-2018)
>
> Somehow, the more recent versions I downloaded a couple of days ago did
> not do the job?!? [beyond my ken]
>

Good to hear!

I'd like to try the Domenator out as well, but I'm wary of installing .dlls
(Windows 10). It's "beyond my Ken" too :=P

Any tips you can give as to where they would go? Or problems to expect?

[Mediat] Re: Domenator, last version [1686 days 12 hours and 51 minutes ago]

Mon, 30 Aug 2021 16:50:00 GMT

Computer mysteries ;-))



I'll post the next version in a few days

Have fun and let me know

Best regards

[Thomas de Groot] Re: Domenator, last version [1686 days 14 hours and 59 minutes ago]

Mon, 30 Aug 2021 14:42:02 GMT

Op 29-8-2021 om 23:26 schreef Mediat:
> Hi Thomas,
> 
> Glad it works.
> 
> If you're interested I'm preparing soome new features (for the fun)
> 
> Best regards
> 
> 
> 
I am certainly interested.

Interestingly: I copied the following dll's from the laptop where 
Domenator /did/ work, to the one where it /didn't/, and Lo! it works 
now! Go understand.

freeglut.dll (23-3-2018)
msvcp140d.dll (19-1-2018)
ucrtbased.dll (14-8-2016)
vcruntime140d.dll (23-3-2018)

Somehow, the more recent versions I downloaded a couple of days ago did 
not do the job?!? [beyond my ken]

-- 
Thomas

[Mediat] Re: Domenator, last version [1687 days 8 hours and 11 minutes ago]

Sun, 29 Aug 2021 21:30:00 GMT

Hi Thomas,

Glad it works.

If you're interested I'm preparing soome new features (for the fun)

Best regards

[Thomas de Groot] Re: Domenator, last version [1687 days 23 hours and 5 minutes ago]

Sun, 29 Aug 2021 06:35:58 GMT

Op 28/08/2021 om 17:13 schreef Mediat:
> Hi Thomas
> 
> Isearch the net for error 0x000007b and here is what I found ;
> 
> The 0x000007b error may be caused by windows system files damage. There can be
> many events which may have resulted in the system files errors.
> 
> Go to Microsoft to download and install Visual C++ Redistributable Packages.
> 
> I hope it'll work
> 
> Best regards
> 
> Philippe
> 

OK. Got it to work on my second laptop, with the dll's of the earlier 
version from 2018. I had lost track of it somehow. A bit confusing as 
that was already version 4.0.
So, something not right indeed with my first laptop it seems. It works 
fine otherwise, but I shall see what I can do.

-- 
Thomas

[Mediat] Re: Domenator, last version [1688 days 14 hours and 26 minutes ago]

Sat, 28 Aug 2021 15:15:00 GMT

Hi Thomas

Isearch the net for error 0x000007b and here is what I found ;

The 0x000007b error may be caused by windows system files damage. There can be
many events which may have resulted in the system files errors.

Go to Microsoft to download and install Visual C++ Redistributable Packages.

I hope it'll work

Best regards

Philippe

[Thomas de Groot] Re: Domenator, last version [1688 days 16 hours and 30 minutes ago]

Sat, 28 Aug 2021 13:11:26 GMT

Op 28-8-2021 om 12:08 schreef Mediat:
>> So, I downloaded all those dll's and put them into the Domenator folder,
>> alongside the exe.
>>
>> "Cannot start the application correctly (0x000007b). Click OK to close
>> the application"
> 
> Hi Thomas,
> 
> Really sorry you loose your time Thomas, I will try to install Domenator on
> another computer and see ; normally i should use only "Visual Studio" DLL.
> 
Thanks for your help Philippe.

> Is your system 32 or 64 bits ? Mine is 64

My system is 64.

> 
> Best regards
> 
> Philippe
> 


-- 
Thomas

[Mediat] Re: Domenator, last version [1688 days 19 hours and 31 minutes ago]

Sat, 28 Aug 2021 10:10:00 GMT

> So, I downloaded all those dll's and put them into the Domenator folder,
> alongside the exe.
>
> "Cannot start the application correctly (0x000007b). Click OK to close
> the application"

Hi Thomas,

Really sorry you loose your time Thomas, I will try to install Domenator on
another computer and see ; normally i should use only "Visual Studio" DLL.

Is your system 32 or 64 bits ? Mine is 64

Best regards

Philippe

[Thomas de Groot] Re: Domenator, last version [1688 days 21 hours and 29 minutes ago]

Sat, 28 Aug 2021 08:12:40 GMT

Op 27-8-2021 om 17:14 schreef Mediat:
> Hi again
> 
> According to Dependency walker, the needed dlls are :
>   VCRUNTIME140D.DLL
>   UCRTBASED.DLL
>   OPENGL32.DLL
>   MSVCP140D.DLL
>   KERNEL32.DLL
>   GLU32.DLL
>   FREEGLUT.DLL
> 

So, I downloaded all those dll's and put them into the Domenator folder, 
alongside the exe.

"Cannot start the application correctly (0x000007b). Click OK to close 
the application"




-- 
Thomas

[Thomas de Groot] Re: Domenator, last version [1688 days 22 hours and 52 minutes ago]

Sat, 28 Aug 2021 06:49:01 GMT

Op 28/08/2021 om 08:32 schreef Thomas de Groot:
> Op 27/08/2021 om 17:14 schreef Mediat:
>> Hi again
>>
>> According to Dependency walker, the needed dlls are :
>>   VCRUNTIME140D.DLL
>>   UCRTBASED.DLL
>>   OPENGL32.DLL
>>   MSVCP140D.DLL
>>   KERNEL32.DLL
>>   GLU32.DLL
>>   FREEGLUT.DLL
>>
>>
> 
> Right. I am stubborn. Now, the intriguing (for me) question is: why do 
> my two laptops have none of those?  ;-)
> 
> Obviously, they are not part of the regular packages...
> 

Update:
Interestingly, I found most of them with an earlier version of Domenator 
(version 4.0) and with Seashell. So you seem to have the exclusivity :-)

I can better download the dll's again, as most of them seem to be from 
years ago (to be on the safe side).

-- 
Thomas

[Thomas de Groot] Re: Domenator, last version [1688 days 23 hours and 9 minutes ago]

Sat, 28 Aug 2021 06:32:05 GMT

Op 27/08/2021 om 17:14 schreef Mediat:
> Hi again
> 
> According to Dependency walker, the needed dlls are :
>   VCRUNTIME140D.DLL
>   UCRTBASED.DLL
>   OPENGL32.DLL
>   MSVCP140D.DLL
>   KERNEL32.DLL
>   GLU32.DLL
>   FREEGLUT.DLL
> 
>

Right. I am stubborn. Now, the intriguing (for me) question is: why do 
my two laptops have none of those?  ;-)

Obviously, they are not part of the regular packages...

-- 
Thomas

[Mediat] Re: Domenator, last version [1689 days 14 hours and 26 minutes ago]

Fri, 27 Aug 2021 15:15:00 GMT

Hi again

According to Dependency walker, the needed dlls are :
 VCRUNTIME140D.DLL
 UCRTBASED.DLL
 OPENGL32.DLL
 MSVCP140D.DLL
 KERNEL32.DLL
 GLU32.DLL
 FREEGLUT.DLL

[Mediat] Re: Domenator, last version [1689 days 20 hours and 51 minutes ago]

Fri, 27 Aug 2021 08:50:00 GMT

>> I stopped downloading them when I got the fifth crash and notice for yet another
dll. Using Win10.


Hi Thomas,

Sorry for that, I suppose you're missing the Microsoft dll, I'm not sure I can
do something to correct this.

Just to tease you, you're missing a "smoothing" feature that I find very
convenient ;-))

Best regards

[Thomas de Groot] Re: Domenator, last version [1689 days 23 hours and 17 minutes ago]

Fri, 27 Aug 2021 06:24:16 GMT

Op 24/08/2021 om 19:13 schreef Mediat:
> Hi
> 
> Here is the last version of this utility (works under windows) that can generate
> shapes form a paper bin, an italian ice cream, many different hats, and of
> course most of the domes you can find on churches, mosques etc.
> 

Good to hear from you. I /think/ I still have Domenator on my system, 
dating from the Moray days. However, this latest version needs too many 
additional dll's for my taste. I stopped downloading them when I got the 
fifth crash and notice for yet another dll. Using Win10.

-- 
Thomas

[Mediat] Domenator, last version [1692 days 12 hours and 26 minutes ago]

Tue, 24 Aug 2021 17:15:00 GMT

Hi

Here is the last version of this utility (works under windows) that can generate
shapes form a paper bin, an italian ice cream, many different hats, and of
course most of the domes you can find on churches, mosques etc.

Once you are happy with your Dome, you can generate OBJ, sTL and INC files, the
last one to be used in POV-Ray, the former ones in 3D viewvers.

The basics :
1) choose a base (easily seen in the top view)
2) choose a slope (easily seen in the side view)
3) optionnaly choose a window (easily seen in the side view)

If you explore the different possibilities I'm sure it is easy to understand how
it works, but feel free to complain (;-), I'll be glad to answer.

PS you may need some dll (freeglut.dll and glew32.dll)

Enjoy

[Thomas de Groot] Poseray v.3.13.29.645: "Export options > Include... [1886 days 21 hours and 31 minutes ago]

Thu, 11 Feb 2021 08:10:08 GMT

The option mentioned in the Subject line of this message works correctly 
when checked, and the download looks like this:

#declare p_map1=pigment {image_map{jpeg "D:/05 - My Programs/Poser Pro 
2014 Content/Runtime/Textures/Animals/HousecatC1.jpg" gamma srgb 
interpolate 2 transmit all 0 } }
#declare p_map2=pigment {image_map{jpeg "D:/05 - My Programs/Poser Pro 
2014 Content/Runtime/Textures/Animals/HousecatEyeC1.jpg" gamma srgb 
interpolate 2 transmit all 0 } }

However, when for some reason, you do not want the file paths included, 
and you uncheck the option, you get this:

#declare p_map1=pigment {image_map{jpeg "/05 - My Programs/Poser Pro 
2014 Content/Runtime/Textures/Animals/HousecatC1.jpg" gamma srgb 
interpolate 2 transmit all 0 } }
#declare p_map2=pigment {image_map{jpeg "/05 - My Programs/Poser Pro 
2014 Content/Runtime/Textures/Animals/HousecatEyeC1.jpg" gamma srgb 
interpolate 2 transmit all 0 } }

Only the drive name (D:) is omitted, but the total rest of the file 
paths is still there.

I seem dimly to remember that this option worked correctly in the past 
under Win7. Could this be a Win10 issue?

If a correction is possible, I would be deeply thankful to FlyerX.

-- 
Thomas

[William F Pokorny] Re: adding SDL to ctags [1923 days 11 hours and 7 minutes ago]

Tue, 5 Jan 2021 18:34:44 GMT

On 1/5/21 5:28 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> Thank you for partly clarifying. I was indeed only aware of the main idea (Only
> stable official pov, "only" available in package repositories). When I said
> "shipped", I meant "out of the box", as available without launching any synaptic
> or package manager whatsoever, just like Vim is for Lubuntu or  Python is
> included out of the box for the one time user to fire at will in almost any
> Linux distribution. Now maybe that was never actually the case for POV? (I
> believed, maybe misconceived, it once was). My question now is why? And could it
> ever?
> 

I suspect it never the case for the most common linux distributions.

For mainstream linux / unix / macOS? distributions I don't think making 
tooling like POV-Ray, Blender, MakeHuman, etc. part of base makes sense.
Including vim, perl, python, the usual shells, etc does.

Most of what makes each distribution unique is the choice of what 
packages are already included and it makes sense to include only those 
most likely to be used by most people directly or indirectly in the 
mainstream ones.

That's not to say there might not be a place for such tools in 
specialized linux distributions aimed at making movies, creating games, 
doing gis/dem stuff or similar. These sorts of code distributions exist 
and they include already extra packages related to their specialization.

Further, if you are using a computer provided by an institution, 
computers are usually installed / maintained using common disk images. 
Each institution would decide what packages are included by default or 
not and some of these might include some form of POV-Ray.

Bill P.

[Mr] Re: adding SDL to ctags [1923 days 19 hours and 6 minutes ago]

Tue, 5 Jan 2021 10:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/3/21 9:17 AM, Mr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> >>
> >> Indeed, the vim support for POV-Ray (3.7) comes by default on most all
> >> unix based systems because it comes with vim itself. POV-Ray (3.7) via
> >> Debian support is there on a good many linux variants too. I installed
> >> v3.7 on my raspberry pi 4 via a usual package install.
> >>
> ...
> >
> > There was a time when POV was shipped with Ubuntu... It would be a good target
> > to try re-establishing that flag, and having integration in such corner stones
> > as VIM, Blender, are a big step in that direction (VIM ships with very selective
> > Lubuntu out of the box!). Slightly off-topic: I don't know why POV was removed
> > from UBUNTU, nor if any other mainstream distro still offers pov package, but
> > now that the relicensing to AGPL has been achieved, maybe there is hope for such
> > a return?
> >
>
> Hmm... I don't think your view of the current POV-Ray availability is
> accurate.
>
> For a long time (Ubuntu 14?) POV-Ray v3.7 has been a package available
> for install from Ubuntu and any other Debian based linux distribution.
> It's certainly still available from Ubuntu 20.04 to which I moved last
> fall.
>
> On my Ubuntu 20.04 upgrade I looked in some detail at the very nice job
> of repackaging the POV-Ray components the Debian support people had
> done. These updates were picked up for Ubuntu 20.04. There is a post in
> povray.unix about this if you're interested.
>
> For v3.8, Dick Balaska provided the only Debian POV-Ray packages of
> which I'm aware - qtpovray 3.8. A native v3.8 POV-Ray Debian package is
> not available for install - as far as I know.
>
> Bill P.

Thank you for partly clarifying. I was indeed only aware of the main idea (Only
stable official pov, "only" available in package repositories). When I said
"shipped", I meant "out of the box", as available without launching any synaptic
or package manager whatsoever, just like Vim is for Lubuntu or  Python is
included out of the box for the one time user to fire at will in almost any
Linux distribution. Now maybe that was never actually the case for POV? (I
believed, maybe misconceived, it once was). My question now is why? And could it
ever?

[William F Pokorny] Re: adding SDL to ctags [1924 days 18 hours and 43 minutes ago]

Mon, 4 Jan 2021 10:58:22 GMT

On 1/3/21 9:17 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>>
>> Indeed, the vim support for POV-Ray (3.7) comes by default on most all
>> unix based systems because it comes with vim itself. POV-Ray (3.7) via
>> Debian support is there on a good many linux variants too. I installed
>> v3.7 on my raspberry pi 4 via a usual package install.
>>
...
> 
> There was a time when POV was shipped with Ubuntu... It would be a good target
> to try re-establishing that flag, and having integration in such corner stones
> as VIM, Blender, are a big step in that direction (VIM ships with very selective
> Lubuntu out of the box!). Slightly off-topic: I don't know why POV was removed
> from UBUNTU, nor if any other mainstream distro still offers pov package, but
> now that the relicensing to AGPL has been achieved, maybe there is hope for such
> a return?
> 

Hmm... I don't think your view of the current POV-Ray availability is 
accurate.

For a long time (Ubuntu 14?) POV-Ray v3.7 has been a package available 
for install from Ubuntu and any other Debian based linux distribution. 
It's certainly still available from Ubuntu 20.04 to which I moved last 
fall.

On my Ubuntu 20.04 upgrade I looked in some detail at the very nice job 
of repackaging the POV-Ray components the Debian support people had 
done. These updates were picked up for Ubuntu 20.04. There is a post in 
povray.unix about this if you're interested.

For v3.8, Dick Balaska provided the only Debian POV-Ray packages of 
which I'm aware - qtpovray 3.8. A native v3.8 POV-Ray Debian package is 
not available for install - as far as I know.

Bill P.

[jr] Re: adding SDL to ctags [1924 days 20 hours and 41 minutes ago]

Mon, 4 Jan 2021 09:00:00 GMT

hi,

"Mr" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > (if you're not using 'vim', look away now..  :-))
> >
> I'm thrilled :-D let me explain : Following initial attempt around these
> newsgroups by Koppi and SDRausty
>
http://news.povray.org/povray.unix/thread/%3Cweb.5703a674be33e802db8f4ad50%40news.povray.org%3E/?mtop=427658
> I gave a successful try at building POV v3.8 and HG POV on Android Phones, using
> Termux. (Recipe here: http://wiki.povray.org/content/HowTo:Install_POV#Termux )
> Then Found out the most practical solutions to edit the pov files there out of
> the box was VIM, also since Vim touch is available from Fdroid, it makes the
> same editor also available outside of Termux. PLUS it did feature POV syntax
> highlighting, so even tighter integration is awesome news !

thank you (I'm thrilled it's being used!)  POV-Ray on a mobile - v cool.


regards, jr.

[jr] Re: New version of Farger.inc [1924 days 20 hours and 46 minutes ago]

Mon, 4 Jan 2021 08:55:00 GMT

hi,

"Sven-Erik Andersen" <sve### [at] gmailcom> wrote:
> Just wanted to say that I have released a new version.
>
> Last year, I stumbled upon a Github repository ...
> that contains a massive collection of
> named colors, currently 27351 unique color names.

:-)

nice!  thanks.  plan to have a look in the coming days.

re the peacock blue you're probably right, cannot remember now what I did.  :-)

regards, jr.

[Mr] Re: adding SDL to ctags [1925 days 15 hours and 21 minutes ago]

Sun, 3 Jan 2021 14:20:06 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/2/21 12:15 PM, Mr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> >> hi,
> >>
> >> (if you're not using 'vim', look away now..  :-))
> >>
> >> most users of 'vim' will be familiar with 'tags' files and the '^]' key combo.
> >> while 'ctags' does not include PovRay SDL, the support is easy to add.  I've
> >> attached an archive containing a source ('sdl.c') and a "diff" to patch a couple
> ...
> >> enjoy, jr.
> >
> > I'm thrilled :-D let me explain : Following initial attempt around these
> > newsgroups by Koppi and SDRausty
> >
http://news.povray.org/povray.unix/thread/%3Cweb.5703a674be33e802db8f4ad50%40news.povray.org%3E/?mtop=427658
> > I gave a successful try at building POV v3.8 and HG POV on Android Phones, using
> > Termux. (Recipe here: http://wiki.povray.org/content/HowTo:Install_POV#Termux )
> > Then Found out the most practical solutions to edit the pov files there out of
> > the box was VIM, also since Vim touch is available from Fdroid, it makes the
> > same editor also available outside of Termux. PLUS it did feature POV syntax
> > highlighting, so even tighter integration is awesome news !
> >
>
> Your post reminds me trying jr's patch is still sitting on my todo list!
> I'm still getting faster after my conversion to vim, but it's now my
> daily editor.
>
> Indeed, the vim support for POV-Ray (3.7) comes by default on most all
> unix based systems because it comes with vim itself. POV-Ray (3.7) via
> Debian support is there on a good many linux variants too. I installed
> v3.7 on my raspberry pi 4 via a usual package install.
>
> Bill P.

There was a time when POV was shipped with Ubuntu... It would be a good target
to try re-establishing that flag, and having integration in such corner stones
as VIM, Blender, are a big step in that direction (VIM ships with very selective
Lubuntu out of the box!). Slightly off-topic: I don't know why POV was removed
from UBUNTU, nor if any other mainstream distro still offers pov package, but
now that the relicensing to AGPL has been achieved, maybe there is hope for such
a return?

[William F Pokorny] Re: adding SDL to ctags [1925 days 16 hours and 16 minutes ago]

Sun, 3 Jan 2021 13:25:07 GMT

On 1/2/21 12:15 PM, Mr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> hi,
>>
>> (if you're not using 'vim', look away now..  :-))
>>
>> most users of 'vim' will be familiar with 'tags' files and the '^]' key combo.
>> while 'ctags' does not include PovRay SDL, the support is easy to add.  I've
>> attached an archive containing a source ('sdl.c') and a "diff" to patch a couple
...
>> enjoy, jr.
> 
> I'm thrilled :-D let me explain : Following initial attempt around these
> newsgroups by Koppi and SDRausty
>
http://news.povray.org/povray.unix/thread/%3Cweb.5703a674be33e802db8f4ad50%40news.povray.org%3E/?mtop=427658
> I gave a successful try at building POV v3.8 and HG POV on Android Phones, using
> Termux. (Recipe here: http://wiki.povray.org/content/HowTo:Install_POV#Termux )
> Then Found out the most practical solutions to edit the pov files there out of
> the box was VIM, also since Vim touch is available from Fdroid, it makes the
> same editor also available outside of Termux. PLUS it did feature POV syntax
> highlighting, so even tighter integration is awesome news !
> 

Your post reminds me trying jr's patch is still sitting on my todo list! 
I'm still getting faster after my conversion to vim, but it's now my 
daily editor.

Indeed, the vim support for POV-Ray (3.7) comes by default on most all 
unix based systems because it comes with vim itself. POV-Ray (3.7) via 
Debian support is there on a good many linux variants too. I installed 
v3.7 on my raspberry pi 4 via a usual package install.

Bill P.

[Mr] Re: New version of NewIOR.inc [1926 days 7 hours and 41 minutes ago]

Sat, 2 Jan 2021 22:00:00 GMT

"Sven-Erik Andersen" <sve### [at] gmailcom> wrote:
> Looks like the attachment didn't get uploaded.

thanks !

[Mr] Re: adding SDL to ctags [1926 days 12 hours and 21 minutes ago]

Sat, 2 Jan 2021 17:20:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> (if you're not using 'vim', look away now..  :-))
>
> most users of 'vim' will be familiar with 'tags' files and the '^]' key combo.
> while 'ctags' does not include PovRay SDL, the support is easy to add.  I've
> attached an archive containing a source ('sdl.c') and a "diff" to patch a couple
> of files.  this first version is v basic, only recognising macros and declare +
> local, but usable.
>
> assuming the source[*] for 'ctags-5.8' in '/tmp/ctags-5.8/', extract the archive
> in '/tmp/'.  copy/move 'sdl.c' into the ctags directory, and cd into it.  then
>   $ zcat ../add.sdl.diff.gz | patch --verbose -p1
>
> that's it.  then the usual './configure  &&  make' etc.
>
> I've installed my copy in my home path, ie '~/bin/', for now.  testing, so far
> so good, hope that (some of) you will provide feedback and suggestions for
> improvements etc.
>
> [*] <http://ctags.sourceforge.net/>
>
>
> enjoy, jr.

I'm thrilled :-D let me explain : Following initial attempt around these
newsgroups by Koppi and SDRausty
http://news.povray.org/povray.unix/thread/%3Cweb.5703a674be33e802db8f4ad50%40news.povray.org%3E/?mtop=427658
I gave a successful try at building POV v3.8 and HG POV on Android Phones, using
Termux. (Recipe here: http://wiki.povray.org/content/HowTo:Install_POV#Termux )
Then Found out the most practical solutions to edit the pov files there out of
the box was VIM, also since Vim touch is available from Fdroid, it makes the
same editor also available outside of Termux. PLUS it did feature POV syntax
highlighting, so even tighter integration is awesome news !

[Sven-Erik Andersen] Re: New version of Farger.inc [1926 days 17 hours and 16 minutes ago]

Sat, 2 Jan 2021 12:25:01 GMT

Just wanted to say that I have released a new version.

Last year, I stumbled upon a Github repository
(https://github.com/meodai/color-names) that contains a massive collection of
named colors, currently 27351 unique color names.

So I have created a new include-file that contains the colors from that
repository. Had to do some conversion of the names in order to get POV-Ray to
accept them since many contain non-ASCII or UNICODE characters or various
punctuation marks.

I have attached the new release, and the latest version you can also find at
https://github.com/SvenErik1968/Farger.inc

Happy New Year, everyone!

Brgds,
Sven-Erik

[Sven-Erik Andersen] Re: New version of Farger.inc [1926 days 20 hours and 16 minutes ago]

Sat, 2 Jan 2021 09:25:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> I see that you've added 'Xona_com_Peacock', but the colour is different from
> "peacock blue"; suggest adding:
>   farge_Peacock_Blue = rgb <0.199219,0.628906,0.785156>
>
> (values from BRLCAD's colour db).
>
>
> regards, jr.

Hi jr,
sorry for not seeing and answering this before.

I took a look at the rgb.txt file from the BRLCAD's source files, and the
Peacock color there is defined as RGB 51, 161, 201.

If you convert that to a POV-Ray style format, that would be rgb <0.2,
0.631372549019608, 0.788235294117647> since you have to divide with 255 that is
the max value and equals 1 (with 0 being the minimum value), and not divide with
256 as you have done here, since that would give you 257 possible color
values...

Brgds,
Sven-Erik

[Thomas de Groot] FieldCam macro by Doctor John - version 4.0 [1969 days 21 hours and 40 minutes ago]

Fri, 20 Nov 2020 08:01:21 GMT

This is version 4.0 of Doctor John's Field Camera, to remediate the 
"falling building syndrome".

-- 
Thomas

[Thomas de Groot] Re: Cloud Shells by Mick Hazelgrove (2004) - mad... [1974 days 21 hours and 45 minutes ago]

Sun, 15 Nov 2020 07:56:30 GMT

Version 2 of Cloud Shells has resulted in a complete rewrite. The macro 
structure has been abandoned in favour of a better user control. All 
transformations of the clouds are controlled by the density parameters. 
Note in particular the use of rotation and scale there. Another 
improvement, imo, is the uniform thickness of the cloud shells from 
zenith to horizon, in contrast to version 1. Also, it is possible to 
choose a clear horizon if that is called for by your scene. Extensive 
comments are added everywhere and all parameters can be changed by the 
user, so feel adventurous and play!

-- 
Thomas

[jr] Re: Cloud Shells by Mick Hazelgrove (2004) - mad... [1987 days 12 hours and 51 minutes ago]

Mon, 2 Nov 2020 16:50:01 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Oh! Sorry. This scene /is/ also the demo scene. Details at the end of
> the file. ;-)

cheers.

> Consider this to be version 1. ...

:-)


regards, jr.

[Thomas de Groot] Re: Cloud Shells by Mick Hazelgrove (2004) - mad... [1987 days 22 hours and 24 minutes ago]

Mon, 2 Nov 2020 07:17:46 GMT

Op 01/11/2020 om 11:25 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Please find here the cloud shell macro developed by Juha
LeppÃ¤lÃ¤ and
>> Mick Hazelgrove in 2004, who are hereby sincerely acknowledged. I
>> cleaned up the code (although I do not remember how the original code
>> looked) and added an atmospheric haze shell to complete the set. I also
>> added a couple of comment lines to the media code to help those less
>> familiar with the use of media.
> 
> thanks.  great looking demo image.  any chance of you posting a simple demo
> scene?
> 

Oh! Sorry. This scene /is/ also the demo scene. Details at the end of 
the file. ;-)

Consider this to be version 1. In the mean time, I have been thinking 
about two improvements. (1) scaling differently the clouds should not be 
done with the Scale parameter as that will unavoidably change also the 
colour of the cloud media. Much better is to do that by scaling the 
density, and rotate the shell afterwards for an interesting view. (2) I 
am not satisfied with the horizon. I think I know how to solve this but 
need a little time. That will be version 2, considering Mick's original 
as version 0.

-- 
Thomas

[jr] Re: Cloud Shells by Mick Hazelgrove (2004) - mad... [1988 days 19 hours and 11 minutes ago]

Sun, 1 Nov 2020 10:30:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Please find here the cloud shell macro developed by Juha
LeppÃ¤lÃ¤ and
> Mick Hazelgrove in 2004, who are hereby sincerely acknowledged. I
> cleaned up the code (although I do not remember how the original code
> looked) and added an atmospheric haze shell to complete the set. I also
> added a couple of comment lines to the media code to help those less
> familiar with the use of media.

thanks.  great looking demo image.  any chance of you posting a simple demo
scene?


regards, jr.

[Thomas de Groot] Cloud Shells by Mick Hazelgrove (2004) - made easy [1988 days 22 hours and 1 minute ago]

Sun, 1 Nov 2020 07:39:56 GMT

Please find here the cloud shell macro developed by Juha LeppÃ¤lÃ¤
and 
Mick Hazelgrove in 2004, who are hereby sincerely acknowledged. I 
cleaned up the code (although I do not remember how the original code 
looked) and added an atmospheric haze shell to complete the set. I also 
added a couple of comment lines to the media code to help those less 
familiar with the use of media.

Enjoy!

-- 
Thomas

[Thomas de Groot] Re: Lawnmaker v1.2 by Uwe Gleiss [1990 days 21 hours and 58 minutes ago]

Fri, 30 Oct 2020 07:43:17 GMT

For those who prefer the zip version, I attach that here, and took the 
opportunity to delete two old files which escaped my scrutiny earlier. ;-)

-- 
Thomas

[Thomas de Groot] Lawnmaker v1.2 by Uwe Gleiss [1996 days 23 hours and 8 minutes ago]

Sat, 24 Oct 2020 06:33:30 GMT

Attached, find the "updated" set of files that form the Lawnmaker 
utility that Uwe Gleiss wrote in 2003. Enjoy!

-- 
Thomas

[jr] Re: ann: df3tcl [2145 days 19 hours and 26 minutes ago]

Thu, 28 May 2020 10:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> happy to announce the resulting 'df3tcl' program, which uses a scripting
> language (Tcl) to create and or modify DF3 files.
>
> the program is still .. under development, so there's a basic Makefile, and a
> (draft) man page, but no './configure' or install target, yet.  ...

the second "progress report".  :-)  added commands to simplify addressing
ranges/subvolumes and updated the man page, including two more examples.  hope
no new bugs were introduced.

enjoy, jr.

[Mr] Re: ann: df3tcl [2147 days 9 hours and 1 minute ago]

Tue, 26 May 2020 20:40:06 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> a recent chance remark in a newsgroup post (Josh: "Are there other programs/ways
> to create simple df3 files of simple shapes?") got me thinking/working, and I am
> happy to announce the resulting 'df3tcl' program, which uses a scripting
> language (Tcl) to create and or modify DF3 files.
>
> the program is still .. under development, so there's a basic Makefile, and a
> (draft) man page, but no './configure' or install target, yet.  you will need to
> install the df3 library first:
> <https://drive.google.com/file/d/1uPn5qxeVSvhbNnwkdLkQuR1qa5fBEwoX/view?usp=sharing>
>
> then extract the archive, change into the directory and 'make check'.  if all's
> well, you will see 'df3' among the interpreter commands listed.  then just copy
> the executable, and the man page, to suitable locations.
>
>
> enjoy, jr.

Thanks !

Just to make sure it doesn't get lost on one of its only potential testers...
The Blender exporter converts smoke simulations to DF3. It's also one of its
available textures.

[jr] ann: df3tcl [2153 days 16 hours and 21 minutes ago]

Wed, 20 May 2020 13:20:00 GMT

hi,

a recent chance remark in a newsgroup post (Josh: "Are there other programs/ways
to create simple df3 files of simple shapes?") got me thinking/working, and I am
happy to announce the resulting 'df3tcl' program, which uses a scripting
language (Tcl) to create and or modify DF3 files.

the program is still .. under development, so there's a basic Makefile, and a
(draft) man page, but no './configure' or install target, yet.  you will need to
install the df3 library first:
<https://drive.google.com/file/d/1uPn5qxeVSvhbNnwkdLkQuR1qa5fBEwoX/view?usp=sharing>

then extract the archive, change into the directory and 'make check'.  if all's
well, you will see 'df3' among the interpreter commands listed.  then just copy
the executable, and the man page, to suitable locations.


enjoy, jr.

[B Gimeno] Re: updated syntax highlighting for gedit [2195 days 12 hours and 56 minutes ago]

Wed, 8 Apr 2020 16:45:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/8/20 7:25 AM, B. Gimeno wrote:
> > James Holsenback <nom### [at] nonecom> wrote:
> >> found that i was missing the albedo keyword, also added max_distance
> >> (uberpov) ... goes in /usr/share/gtksourceview-3.0/language-specs
> >
> > Update to version 3.8 now includes:
> >
> ...
> >
> Thank you!
>
> Bill P.

My first mistake was to have published it without having thoroughly tested it.
Now I was reviewing all the standard version 3.8 inclusion files and the list of
reserved keywords in case I had left something else.

What worries me after reviewing the file with the WINPOV editor and
consulting the oracle, is that dark, ancient and bloody sacred war between tabs
and white spaces everywhere. Free trolls food!

It's like having read a grimoire from the Unseen University's Library taking
advantage of the fact that the librarian was dispatching his ration of bananas.

When I finish consulting include files and decide how to homogenize styles I
will publish it again.

B Gimeno

Pd. However, a great job on the part of those who started this task. Thank you.

[William F Pokorny] Re: updated syntax highlighting for gedit [2195 days 15 hours and 41 minutes ago]

Wed, 8 Apr 2020 14:00:24 GMT

On 4/8/20 7:25 AM, B. Gimeno wrote:
> James Holsenback <nom### [at] nonecom> wrote:
>> found that i was missing the albedo keyword, also added max_distance
>> (uberpov) ... goes in /usr/share/gtksourceview-3.0/language-specs
> 
> Update to version 3.8 now includes:
> 
...
> 
Thank you!

Bill P.

[B Gimeno] Re: updated syntax highlighting for gedit [2195 days 18 hours and 11 minutes ago]

Wed, 8 Apr 2020 11:30:00 GMT

James Holsenback <nom### [at] nonecom> wrote:
> found that i was missing the albedo keyword, also added max_distance
> (uberpov) ... goes in /usr/share/gtksourceview-3.0/language-specs

Update to version 3.8 now includes:

blend_gamma
blend_mode
bokeh
bt709
bt2020
dictionary
grey
optional
potential
user_defined projection
user_defined pattern
CLab2RGB
CRGB2Lab
CCLab2RGB_D65
CCRGB2Lab_D65x

Info obtained from:

http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Version_3.8


Regards,
bgimeno

[jr] Re: stl2gts utility [2213 days 15 hours and 31 minutes ago]

Sat, 21 Mar 2020 14:10:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/20/20 9:03 PM, jr wrote:
> > the archive contains source and Makefile for the 'stl2gts' utility, which
> > converts STL data (either ASCII or binary) to the GTS format.
>
> Is this converter unrelated to the converter of the same name floating
> about on the web?

oh dear, lacking .. due diligence.  entirely unrelated[*].  had not even checked
for potential name clash.  :-(

will publish any update with a different name, thanks for the pointer.

[*] and more capable, judging by its man page.

regards, jr.

[William F Pokorny] Re: stl2gts utility [2213 days 16 hours and 46 minutes ago]

Sat, 21 Mar 2020 12:55:43 GMT

On 3/20/20 9:03 PM, jr wrote:
> hi,
> 
> the archive contains source and Makefile for the 'stl2gts' utility, which
> converts STL data (either ASCII or binary) to the GTS format.
> 
> to build, extract the archive, change into the directory, and 'make'.  there's
> no  install target, just copy/move the file into a PATH directory.
> 
> 
> enjoy, jr.
> 

Is this converter unrelated to the converter of the same name floating 
about on the web?

Bill P.

[jr] stl2gts utility [2214 days 4 hours and 36 minutes ago]

Sat, 21 Mar 2020 01:05:01 GMT

hi,

the archive contains source and Makefile for the 'stl2gts' utility, which
converts STL data (either ASCII or binary) to the GTS format.

to build, extract the archive, change into the directory, and 'make'.  there's
no  install target, just copy/move the file into a PATH directory.


enjoy, jr.

[jr] Re: New version of Farger.inc [2218 days 4 hours and 36 minutes ago]

Tue, 17 Mar 2020 01:05:01 GMT

hi,

"Sven-Erik Andersen" <sve### [at] gmailcom> wrote:
> Releases a large update. The include-files have been split into separate files.
> Added more named colors, a total now of 6568 colors.
>
> Also improved the simple documentation with a separate HTML-file for each
> include-file that shows the color name, the RGB HEX-value, a color sample and a
> button that will copy the color name to the clipboard.
>
> Updated version is available on GitHub at
> https://github.com/SvenErik1968/Farger.inc/
>
> Brgds,
> Sven-Erik

I see that you've added 'Xona_com_Peacock', but the colour is different from
"peacock blue"; suggest adding:
  farge_Peacock_Blue = rgb <0.199219,0.628906,0.785156>

(values from BRLCAD's colour db).


regards, jr.

[Melody] Re: New version of Farger.inc [2266 days 2 hours and 11 minutes ago]

Wed, 29 Jan 2020 03:30:00 GMT

the first one ... doh.

goes in send2picker() {
// newpicker();
JC[wkey].value = e.value;
}


its never done

[Melody] Re: New version of Farger.inc [2266 days 3 hours and 41 minutes ago]

Wed, 29 Jan 2020 02:00:00 GMT

and it was being skiddish, which made me study it,

back to class ID method, updates have to be handled, as before.

end of send2picker() {
  call newpicker();
}

just do all.
 dont know the property for updating one. I got enough to remember.

that's all folks.

[Melody] Re: New version of Farger.inc [2266 days 5 hours and 26 minutes ago]

Wed, 29 Jan 2020 00:15:01 GMT

only thing worse than posting junk is not coming back to fix it.

learned a lot, like, can't just add class= in the input tag,
and access properties.

rather than hacking a couple globals, which was all I needed;
instead, added this.open property. more complicated.
u have to do it all yourself that way.

showOnClick = false;
use the input tag events.

show and hide each picker yourself.
only picker that can set .open to false must be closed first.
just opening another picker only transforms the picker,
didn't actually call .hide(); so u have to do it.

i mean if u want it right.

[Melody] Re: New version of Farger.inc [2269 days 13 hours and 1 minute ago]

Sat, 25 Jan 2020 16:40:00 GMT

This came together in only hours not days,
 with all the previous work behind it.

Smaller faster using element events.
Still had to have the open/close trigger.
Using jscolor 2.0.5. Element events seem to have improved.
Knows which picker was opened and in use, and which picker was used.
Got to toss out 10 functions.

[Melody] Re: New version of Farger.inc [2269 days 17 hours and 51 minutes ago]

Sat, 25 Jan 2020 11:50:00 GMT

jscolor 1.4.2
All previously described quirks are gone.
No reopening to get the data, and consistently.
Have not seen an error for some time.

So I get the new one, 2.0.5

It's way different. Hacking with
if (this.valueElement.value) MYColor = '#'+this.valueElement.value;

this.show() is a good time to set vars, to get the color on open. WORKS!!

OK set a color with picker, fail permanently, menu reload, still broken, no
errors from the console. Must command line reload to restore limited function.

This must be rare, bugless interface with multiple jsColor pickers.
Running in Firefox 25, 45 and latest Chrome. here's jsColor 1.4.2 ...

Setting MYColor in 1.4.2 from only two places. everything working.
this.fromHSV()
function redrawPad()

No errors.
Click upper right field to copy picker-output in 3 forms! sweet.
ctrl shift alt click to send palette selection to 3 picker fields and translate.
And jscolor knows all about it; so that's your color on open.

[Melody] Re: New version of Farger.inc [2270 days 12 hours and 36 minutes ago]

Fri, 24 Jan 2020 17:05:01 GMT

// #declare X11_Web_Purple = rgb <0.501961, 0, 0.501961>;
// #declare farge_Purple_Web = rgb <0.501961, 0, 0.501961>;
// #declare farge_Patriarch = rgb <0.501961, 0, 0.501961>;

which ones should I delete ?

[Melody] Re: New version of Farger.inc [2270 days 13 hours and 16 minutes ago]

Fri, 24 Jan 2020 16:25:00 GMT

got goofy to take a hike, description for hacking jscolor:

pickeropen = 1;pickeropen = 0;MYColor = '#'+value;
hidePicker() know the state
showPicker() know the state and halt lower layer functions.
fromHSV() only set on new color selection, not on close.
drawPicker() get color on open.
if (valueElement.value) MYColor = '#'+valueElement.value;

script sends new color to text input - update = newpicker();

this way u dont have to know which picker you're using,
when showing results.

[Melody] Re: New version of Farger.inc [2270 days 14 hours and 51 minutes ago]

Fri, 24 Jan 2020 14:50:01 GMT

got it! next version maybe. If you cant wait,

move MYColor = '#'+value;

to end of
this.exportColor = function(flags) {

like so ...
MYColor = '#'+value;
this.exportColor(flags);

it was setting, as if closing happened after opening new pricker.

goofy got fixed.

[Melody] Re: New version of Farger.inc [2270 days 15 hours and 6 minutes ago]

Fri, 24 Jan 2020 14:35:01 GMT

thought it too much find in the maze, I was wrong.

EASY FIX. add this to jscolor.js -
IN function drawPicker(x, y) {
if (valueElement.value) MYColor = '#'+valueElement.value;

opens and gets the new color, yea.

only goofy part is if u open another while one is open.
that case, drawPicker() doesn't seem to fly first time or something.

[Melody] Re: New version of Farger.inc [2270 days 16 hours and 51 minutes ago]

Fri, 24 Jan 2020 12:50:00 GMT

"Melody" <nomail@nomail> wrote:
> v.8 Changes
>  close and reopen same, set to this color.
>   down clicks on Picker always set this color.
had I communication skills, I might have said something more clear.

 close and reopen same, Picker set to the sent-color.
  down clicks on Picker always set a new selected color.
quirky.

[Melody] Re: New version of Farger.inc [2270 days 17 hours and 1 minute ago]

Fri, 24 Jan 2020 12:40:01 GMT

v.8 Changes

comments removed from operations that need speed.
hue error handling.
added variables for decimal output.
clipboard extended to any color set with "Cb" checked.
but unfortunately,
copy event closes the jsPicker layer by focus change. not a bug.
should be clipboard("text")! mirc has it. another case for DIY.
clipboard had to select text. added deselect.

send palette color to Picker,
left mouseClick and ctr = 1, shift = 2, alt = 3rd Picker.

QUIRKS that stick:
open/close/reopen Picker before it gets the new color.

open a Picker, by clicking on text input ...
open another Picker, MYColor is set to previous picker.
 close and reopen same, set to this color.
  down clicks on Picker always set this color.

[Melody] Re: New version of Farger.inc [2271 days 14 hours and 1 minute ago]

Thu, 23 Jan 2020 15:40:00 GMT

function hsl2rgb(h, s, l) {
....
  echo("That was not a color! hsl2rgb()")
  return [0,0,0];
}

both those functions ought to,
not leave a condition where it could return nothing.
check for out of range input.
and give some heads up.

more to do.

[Melody] Re: New version of Farger.inc [2271 days 14 hours and 56 minutes ago]

Thu, 23 Jan 2020 14:45:01 GMT

too many changes to list,
text area (good for debugging)
color doesn't change without breaking a leg to do it.

changed to text input.
dark color with white text,
light colr with black text.

and all previous changes,
lucky number 7 is here.

[Melody] Re: New version of Farger.inc [2271 days 16 hours and 41 minutes ago]

Thu, 23 Jan 2020 13:00:00 GMT

so you open and close a picker but didn't set a color. MYColor (not the other 4)
got set anyway, field will be changed unnecessarily for other upClicks.
 more changes...

function mouseUp(e) {
  if (pickeropen) showpicker();
}

function showpicker() {
  if ((MYColor) && (pickeropen)) { /// will move, not set.
}
function mouseDwn() {
  // echo(" ");
}

I mean, if you want something right.
That should be all the bugs from adding 4 pickers that can work on top.

happy coloring.

[Melody] Re: New version of Farger.inc [2271 days 17 hours and 26 minutes ago]

Thu, 23 Jan 2020 12:15:00 GMT

* my 3 global hacks = pickeropen = 1;pickeropen = 0;MYColor = '#'+value;
(Didn't figure a way to access existing state.)

Now it knows what it's doing on top of another layer.
Wont be pulling off uncontrolled double operations.
Was like insulting, heh.

[Melody] Re: New version of Farger.inc [2271 days 22 hours and 26 minutes ago]

Thu, 23 Jan 2020 07:15:00 GMT

Default off til you need it,
Cb<input type="checkbox" id="clip"/>

And in the function buffer ... there are 2,
which use clipboard();

if (document.getElementById("clip").checked) clipboard();

[Melody] Re: New version of Farger.inc [2271 days 23 hours and 26 minutes ago]

Thu, 23 Jan 2020 06:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, this is very cool - most especially since it runs in JS, which is fast,
> real-time, and runs in a browser.
>
> This would be a great cross-platform pigment-map editor if JS has easily
> editable sliders or something like that.  No clunky OS-dependent installation,
> nearly everyone always has a browser window of some sort open...
>
>
>
> Such a thing would be especially useful for constructing the pigment_maps for
> patterns, since it's a hard thing to visualize, code, edit, and iteratively
> render until it's "right"/pleasing.
>
>
http://news.povray.org/povray.binaries.images/thread/%3C5acf08bc%241%40news.povray.org%3E/
>
> or for spitting out a prototype pigment_map for something sampled from an image,
> that could them be fine-tuned and adjusted.
>
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.58cfc0cf857600e8c437ac910%40news.povray.org%3E/?mtop=41

Dream realized - Java is the cross platform solution.
Well if you like that, here's more.
Added 4 JS color pickers.

Firefox 25, no clipboard, but everything else is fine.
Latest Chrome, everything fine.I'll post an image, and this url.
color pickers not using clipboard ... displays 3 forms on the BGcolor.
I think it needs a switch to turn clipboard on off maybe.

[Bald Eagle] Re: New version of Farger.inc [2272 days 8 hours and 51 minutes ago]

Wed, 22 Jan 2020 20:50:00 GMT

So, this is very cool - most especially since it runs in JS, which is fast,
real-time, and runs in a browser.

This would be a great cross-platform pigment-map editor if JS has easily
editable sliders or something like that.  No clunky OS-dependent installation,
nearly everyone always has a browser window of some sort open...



Such a thing would be especially useful for constructing the pigment_maps for
patterns, since it's a hard thing to visualize, code, edit, and iteratively
render until it's "right"/pleasing.

http://news.povray.org/povray.binaries.images/thread/%3C5acf08bc%241%40news.povray.org%3E/

or for spitting out a prototype pigment_map for something sampled from an image,
that could them be fine-tuned and adjusted.

http://news.povray.org/povray.binaries.images/thread/%3Cweb.58cfc0cf857600e8c437ac910%40news.povray.org%3E/?mtop=41

[Melody] Re: New version of Farger.inc [2272 days 15 hours and 46 minutes ago]

Wed, 22 Jan 2020 13:55:01 GMT

Here's the whole thing if u don't want to DIY.
Added 1920 unique names for the hue colors.
Maybe it's done now, always something else.

[Melody] Re: New version of Farger.inc [2272 days 16 hours and 31 minutes ago]

Wed, 22 Jan 2020 13:10:00 GMT

Here's the last function to replace.
Returns the hue color you click, POV color 0-1;

function colorhue(i) {
  var z = 320;
  var v = .3 + .12 * i / z;
  var h = 1.0 - ((i % z) / z);
  if (i < 960) return "<"+roundv(hsv2rgb(h,1,v),6)+">";
  v = .33 + .12 * (i%960) / z;
  return "<"+roundv(hsl2rgb(h,1,v),6)+">";
}

[Melody] Re: New version of Farger.inc [2272 days 17 hours and 46 minutes ago]

Wed, 22 Jan 2020 11:55:01 GMT

so thats what happens when you go over 1 input.
you get negative numbers, now I know.

that routine wasnt supposed the increment saturation, it was already at 1, I
forgot that.

[Melody] Re: New version of Farger.inc [2272 days 18 hours and 1 minute ago]

Wed, 22 Jan 2020 11:40:01 GMT

And again !! in previous version, old html was saved. doh!
Previous wasn't offset 22.

Now, this one is for Michael who seemed to not get HSV.
Button says click. Click it! HSV HSL ta dah.
Example usage.

Unnamed - just says "rgb" til I figure out what colorhue(i) will be;
to get back to POV colors, reload.

In C, the routines ran fine. Translated to java was giving negative numbers.
I usually find that kind of stuff. Nope. I just clamped 0-1 and it's fine.

[Melody] Re: New version of Farger.inc [2274 days 23 hours and 41 minutes ago]

Mon, 20 Jan 2020 06:00:00 GMT

> 0 not 22,

offset a layer, have to remember the offset. doh
here's the update.

[Sven-Erik Andersen] Re: New version of Farger.inc [2275 days 8 hours and 26 minutes ago]

Sun, 19 Jan 2020 21:15:01 GMT

Releases a large update. The include-files have been split into separate files.
Added more named colors, a total now of 6568 colors.

Also improved the simple documentation with a separate HTML-file for each
include-file that shows the color name, the RGB HEX-value, a color sample and a
button that will copy the color name to the clipboard.

Updated version is available on GitHub at
https://github.com/SvenErik1968/Farger.inc/

Brgds,
Sven-Erik

[Melody] Re: New version of Farger.inc [2276 days 4 hours and 1 minute ago]

Sun, 19 Jan 2020 01:40:00 GMT

Forgot something. Now can click on text field.
Don't need to unless clipboard fails.
function mousedwn() looks like this.

  var m = Math.floor(Width/patchSize);
  if ((mousex < (patchSize * m)) && (mousey > 22)) {
    echo(" ");
    m = whichcolor();
    patchHighLight(m);
    buffer(m);
  }

[Melody] Re: New version of Farger.inc [2276 days 18 hours and 21 minutes ago]

Sat, 18 Jan 2020 11:20:00 GMT

function patchHighLight(i) {
  var w = Width, sz = patchSize;
  var m = Math.floor(w/sz);
  var x = (i % m) * sz;
  var y = Math.floor(i / m) * sz;
  GG.setColor("#FFFFFF");
  GG.drawRect(x,y,sz,sz);
  GG.paint();
}

and add patchHighLight(m);
in mouseDwn

now you need to invert the color of the frame;
white on white wont do much, heh.
i see names then go, ??? where was that ??
 lol

highlight it.

[Melody] Re: New version of Farger.inc [2276 days 19 hours and 21 minutes ago]

Sat, 18 Jan 2020 10:20:01 GMT

/**  Using clipboard - needs a recent version - Chrome is OK -
 CLICK A COLOR, = COPY to Clipboard */

var nColors = 1819, mousex, mousey, GG, Width = 1260, patchSize = 21;

// "#declare MediumSlateBlue = color red 0.498039 blue 1.0;" ,
// "#declare MediumSpringGreen = color red 0.498039 green 1.0;" ,
// had no green blue --- yellow had no spaces
// ? "#declare Mica = color Black; // needed in textures.inc" , fits nothing
//"#declare OrangeRed = color red 1.0 green 0.25;" no blue

So that's 3, I don't really know the real color. Everything patched.
Set patchSize in drawpalette.js if they don't all fit in your browser frame.

Can't draw in java yet? You can now. Sweet.

[Sven-Erik Andersen] Re: New version of Farger.inc [2283 days 14 hours and 51 minutes ago]

Sat, 11 Jan 2020 14:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> thanks, very useful, except..  :-)  the page being so large will benefit from
> having links to get to each table, imo.  the attached patch adds navigation, to
> apply cd into same directory as 'farger.inc.html', then:
>   $ zcat /path/to/farger.nav.diff.gz | patch --verbose -p1
>
>
> regards, jr.

Thanks jr! I have added the navigation to the HTML-file.

Updated version is available on Github:
https://github.com/SvenErik1968/Farger.inc

[jr] Re: New version of Farger.inc [2283 days 18 hours and 46 minutes ago]

Sat, 11 Jan 2020 10:55:01 GMT

hi,

"Sven-Erik Andersen" <sve### [at] gmailcom> wrote:
> New version where I fixed a wrongly named color, and I created a HTML-file
> showing the various named colors.

thanks, very useful, except..  :-)  the page being so large will benefit from
having links to get to each table, imo.  the attached patch adds navigation, to
apply cd into same directory as 'farger.inc.html', then:
  $ zcat /path/to/farger.nav.diff.gz | patch --verbose -p1

regards, jr.

[Sven-Erik Andersen] Re: New version of Farger.inc [2284 days 20 hours and 11 minutes ago]

Fri, 10 Jan 2020 09:30:01 GMT

New version where I fixed a wrongly named color, and I created a HTML-file
showing the various named colors.

Brgds,
Sven-Erik Andersen

[jr] Re: adding SDL to ctags [2289 days 7 hours and 31 minutes ago]

Sun, 5 Jan 2020 22:10:01 GMT

hi,

the first version posted would not "see" macros/declares/locals when not the
first item on the line, eg "#if (flag_) #local a_ = 1; #end"  misses the '#local
a_', now corrected.

I find the cross-referencing option too worth having, the output shown is
produced with:

  $ cd /usr/local/share/povray-3.8/include
  $ ctags -x debug.inc
  DEBUG            variable     13 debug.inc        #declare DEBUG = yes;
  DEBUG            variable     19 debug.inc        #macro Set_Debug(Bool)
#declare DEBUG = Bool; #end
  DEBUG_MCR        variable     11 debug.inc        #declare DEBUG_MCR = true;
  Debug            macro        29 debug.inc        #macro Debug(Condition,
Message)
  Debug_Inc_Stack  macro        15 debug.inc        #macro Debug_Inc_Stack()
  Debug_Message    macro        22 debug.inc        #macro Debug_Message(Str)
  Error            macro        39 debug.inc        #macro Error(Condition,
Message)
  Set_Debug        macro        19 debug.inc        #macro Set_Debug(Bool)
#declare DEBUG = Bool; #end
  View_POV_Include_Stack variable     16 debug.inc        #declare
View_POV_Include_Stack = 1;
  Warning          macro        34 debug.inc        #macro Warning(Condition,
Message)


enjoy, jr.

[jr] adding SDL to ctags [2292 days 13 hours and 36 minutes ago]

Thu, 2 Jan 2020 16:05:01 GMT

hi,

(if you're not using 'vim', look away now..  :-))

most users of 'vim' will be familiar with 'tags' files and the '^]' key combo.
while 'ctags' does not include PovRay SDL, the support is easy to add.  I've
attached an archive containing a source ('sdl.c') and a "diff" to patch a couple
of files.  this first version is v basic, only recognising macros and declare +
local, but usable.

assuming the source[*] for 'ctags-5.8' in '/tmp/ctags-5.8/', extract the archive
in '/tmp/'.  copy/move 'sdl.c' into the ctags directory, and cd into it.  then
  $ zcat ../add.sdl.diff.gz | patch --verbose -p1

that's it.  then the usual './configure  &&  make' etc.

I've installed my copy in my home path, ie '~/bin/', for now.  testing, so far
so good, hope that (some of) you will provide feedback and suggestions for
improvements etc.

[*] <http://ctags.sourceforge.net/>


enjoy, jr.

[Melody] Re: HSV HSL color script for mirc [2296 days 16 hours and 41 minutes ago]

Sun, 29 Dec 2019 13:00:01 GMT

line 248  crayola_farger.mrc - wrong file for this project. not irc.dll

math.dll or $lib
sheesh and in the dll

was almost ready, doh, Thomas asked,
so I had to show heh

all patched up now. : )

[Melody] Re: HSV HSL color script for mirc [2296 days 18 hours and 6 minutes ago]

Sun, 29 Dec 2019 11:35:01 GMT

just do this -- line 150 and 165

paste over %sat
$remove(%sat,.)

so easy

[Melody] Re: HSV HSL color script for mirc [2296 days 18 hours and 11 minutes ago]

Sun, 29 Dec 2019 11:30:00 GMT

as suspected, decimal point names wont fly.
#declare hsv_0.8_318 = rgb < 0.6,0.147,0.12 >;

next version

[Melody] HSV HSL color script for mirc [2296 days 19 hours and 1 minute ago]

Sun, 29 Dec 2019 10:40:00 GMT

HSV HSL color script for mIRC, spitting out povray scripted colors.

mIRC is vital to have something this easy, if you need to sort something, or
prepare a data file, etc etc. perfect when I needed to sort lon lat for DEM
placement -- pop into a sort window, you're done in like 10 minutes with writing
a sort task.

Script is not case sensitive, to the 6th decimal. You need around
9-place-accuracy to calc a planetarium. I included math.dll to the 15th, for
when accuracy is a must.

Recommend mirc6.35, not the latest; you dont need it. This will open a new world
of files and programming, if u go online and find me ... heh.

In a read file, some simple instructions to load a script, for 1st timers just
getting mirc.

mIRC running might be all one needs, and of course everything is made for
windows. you NEED windoze 7. win 10 is a virus. I took the laptop back and told
Fry's to delete it and put on win7.

current pallet, 1920 visible colors in 3 sv/sl shades. 320 hue * 6.

[Melody] Re: New version of Farger.inc [2298 days and 36 minutes ago]

Sat, 28 Dec 2019 05:05:00 GMT

drawrect width 245 to 300

farge_International_Orange_Golden_Gate_Bridge

think that's the longest one. not important.

need a color? need to see that color.

[Melody] Re: New version of Farger.inc [2298 days 1 hour and 6 minutes ago]

Sat, 28 Dec 2019 04:35:01 GMT

didnt see what to do at first.

v3
mouse-over spits out names onscreen at thumbs end.
file loaded in mem, held for 60 secs, auto unload.
less tax on the hard drive if $read must open file every time, I suppose.
this is $fread.
click thumb if u want to save to clipboard.
popup copied name for 6 secs.

good example for anyone who never scripted mirc.

[Melody] Re: New version of Farger.inc [2298 days 18 hours and 46 minutes ago]

Fri, 27 Dec 2019 10:55:00 GMT

"Sven-Erik Andersen" <sve### [at] gmailcom> wrote:
>
> I have corrected the erroneously use of srgb.

Script v2

messed up brain farts, ; v. // comment prefix mistake

now reads unedited Farger.inc file, (price: spaces between colors sets, smaller
thumbs, make up for wasted space.) no zip needed.

not just to clipboard; name and color to status for review, active status
window.

[Sven-Erik Andersen] Re: New version of Farger.inc [2298 days 20 hours and 36 minutes ago]

Fri, 27 Dec 2019 09:05:00 GMT

"Melody" <nomail@nomail> wrote:
> "Sven-Erik Andersen" <sve### [at] gmailcom> wrote:
> > I have updated my Farger-inc include file with an extensive list of named
> > colors.
> >
> > It is available on GitHub:
> >
> > https://github.com/SvenErik1968/Farger.inc
> >
> > Brgds,
> > Sven-Erik Andersen
>
> click-on-thumbnail script, setting color name in clipboard.
>
> srgb ??

I have corrected the erroneously use of srgb.

[Melody] Re: New version of Farger.inc [2299 days and 51 minutes ago]

Fri, 27 Dec 2019 04:50:00 GMT

"Sven-Erik Andersen" <sve### [at] gmailcom> wrote:
> I have updated my Farger-inc include file with an extensive list of named
> colors.
>
> It is available on GitHub:
>
> https://github.com/SvenErik1968/Farger.inc
>
> Brgds,
> Sven-Erik Andersen

click-on-thumbnail script, setting color name in clipboard.

srgb ??

[Melody] Re: 3.63 Console [2299 days 4 hours and 41 minutes ago]

Fri, 27 Dec 2019 01:00:01 GMT

"Melody" <nomail@nomail> wrote:
> post commands ok
> frame animation ok
>
> example. console.ini

forgot to mention in that ini file ... lastest imageMagick failed.
waste no time -- using windoze 7 -

; ImageMagick-6.3.7-2-Q16-windows-dll.exe -version that works

[Sven-Erik Andersen] Re: New version of NewIOR.inc [2302 days 19 hours and 26 minutes ago]

Mon, 23 Dec 2019 10:15:00 GMT

Looks like the attachment didn't get uploaded.

[Thomas de Groot] Re: New version of NewIOR.inc [2302 days 19 hours and 39 minutes ago]

Mon, 23 Dec 2019 10:02:10 GMT

Op 23/12/2019 om 10:35 schreef Sven-Erik Andersen:
> I have finally updated my old NewIOR.inc file (first version released in 1994,
> the previous version i 2001…).
> 
> The files are now also available on GitHub at:
> 
> https://github.com/SvenErik1968/NewIOR
> 
> The files now contains 3617 IOR-values. Have also added links to the sources of
> the values, and expanded the list of websites of interest.
> 
> I hope this can be of use for some of you.
> 
> Wish you all a Merry X-mas, or 'God jul' as we say in Norway.
> 
> Brgds,
> Sven-Erik Andersen
> 
> 
> 
> 

Thank you indeed!

And a good Christmas too.

-- 
Thomas

[Sven-Erik Andersen] New version of Farger.inc [2302 days 20 hours and 1 minute ago]

Mon, 23 Dec 2019 09:40:01 GMT

I have updated my Farger-inc include file with an extensive list of named
colors.

It is available on GitHub:

https://github.com/SvenErik1968/Farger.inc

Brgds,
Sven-Erik Andersen

[Sven-Erik Andersen] New version of NewIOR.inc [2302 days 20 hours and 1 minute ago]

Mon, 23 Dec 2019 09:40:00 GMT

I have finally updated my old NewIOR.inc file (first version released in 1994,
the previous version i 2001…).

The files are now also available on GitHub at:

https://github.com/SvenErik1968/NewIOR

The files now contains 3617 IOR-values. Have also added links to the sources of
the values, and expanded the list of websites of interest.

I hope this can be of use for some of you.

Wish you all a Merry X-mas, or 'God jul' as we say in Norway.

Brgds,
Sven-Erik Andersen

[Melody] Re: 3.63 Console [2310 days 4 hours and 41 minutes ago]

Mon, 16 Dec 2019 01:00:01 GMT

in case you were wondering, yeah you want the console app.
https://sourceforge.net/p/console/wiki/Home/
800768
you got windoze, u need all the help u can get.

[Melody] Re: 3.63 Console [2310 days 4 hours and 46 minutes ago]

Mon, 16 Dec 2019 00:55:00 GMT

post commands ok
frame animation ok

example. console.ini

[Melody] Re: DEM2POV v1.4 [2314 days 2 hours and 51 minutes ago]

Thu, 12 Dec 2019 02:50:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 08/12/2019 om 23:38 schreef Melody:
> > looks like 1.9 mrc is ready.
> > just need mirc to run it.
> >
> > 2 minutes I'll find something to fix about it heh
> >
>
> mirc???
>
> --
> Thomas

mirc, chat network, DCC file transfers with resume.
the easiest scripting. full range of commands.
to the 6th decimal.
can make your own plugin dll for it,
so anything you want.

must have software. v6.35 is best

[Thomas de Groot] Re: DEM2POV v1.4 [2316 days 22 hours and 9 minutes ago]

Mon, 9 Dec 2019 07:31:54 GMT

Op 08/12/2019 om 23:38 schreef Melody:
> looks like 1.9 mrc is ready.
> just need mirc to run it.
> 
> 2 minutes I'll find something to fix about it heh
> 

mirc???

-- 
Thomas

[Melody] Re: DEM2POV v1.4 [2317 days 7 hours and 1 minute ago]

Sun, 8 Dec 2019 22:40:00 GMT

looks like 1.9 mrc is ready.
just need mirc to run it.

2 minutes I'll find something to fix about it heh

[Melody] Re: DEM2POV v1.4 [2319 days 23 hours and 51 minutes ago]

Fri, 6 Dec 2019 05:50:00 GMT

added this to next one if there is a next one,
sorter expects u have a macro like,

#macro pce(hf,tx,tz,mxev)
height_field {
  tga hf   // x 0-1.0 y 0-1.0 z 0-1.0
  smooth
  pigment {
    gradient y
    color_map {
      [0.0 color <0.25 , 0.25 , 1.0>]
      [0.01 color <0.2 , 0.4 , 0.25>]
      [0.1 color <.2 , 0.5 , 0.0>]
      // [0.3 color <.3 , 0.4 , 0.0>]
      [0.2 color <.4 , 0.3 , 0.0>]
      [0.5 color <.3,.18 , 0.32>]
      [0.9 color <.2,.18 , 0.22>]
      [0.95 color <1,1,1>]
      [1.0 color <0.25 , 0.25 , 1.0>]
    }
    //scale  1
  }
  finish {
    crand 0.025         // dither  - not used often.
    ambient 0.2         // Very dark shadows
    diffuse 0.8         // Whiten the whites
    //phong 0.2          // shiny
    // phong_size 100.0    // with tight highlights
    // specular 0.5
    roughness 0.15
  }
  translate <tx, 0,tz>
  scale < 300, 50, 300 >
}
#end

make something good

[Melody] Re: DEM2POV v1.4 [2320 days and 41 minutes ago]

Fri, 6 Dec 2019 05:00:00 GMT

go ahead try and break it.
got defaults if one fails to get it,
its got input request for old header.
 what you want to do? because you got no lon lats to sort by like Hawaii.
suggest next step for sorting. etc etc

figure it will fly, now

[Melody] Re: DEM2POV v1.4 [2320 days 1 hour and 1 minute ago]

Fri, 6 Dec 2019 04:40:01 GMT

done.
yeah right.

[Melody] Re: DEM2POV v1.4 [2320 days 2 hours and 21 minutes ago]

Fri, 6 Dec 2019 03:20:00 GMT

just dont use the older ones.
its never done.

[Melody] Re: DEM2POV v1.4 [2320 days 2 hours and 36 minutes ago]

Fri, 6 Dec 2019 03:05:00 GMT

and again ... heh

sorted longitudes,
then took all the same longitudes, and sorted by latitude.

in the mix, if there were only one longitude ... oops.
fixed.

111.25 - 111.25 ) * 8
pce( "wupatkise.tga" , 0 *n, 0 *n,0)
111.25 - 111.25 ) * 8
pce( "wupatkine.tga" , 1 *n, 0 *n,0)
111.375 - 111.25 ) * 8
pce( "wupatkisw.tga" , 0 *n, 1 *n,0)
112.5 - 111.25 ) * 8
pce( "tinhouse.tga" , 1 *n, 10 *n,0)


jillion other things fixed

[Melody] Re: DEM2POV v1.4 [2320 days 20 hours and 51 minutes ago]

Thu, 5 Dec 2019 08:50:01 GMT

bug fix 1a

dont have to test it, I can see, names with spaces
in the NEW header wont fly,

make it this way, separator should be a comma

 formatname {
 ...
  if (%headformat) %r = $gettok(%r,1,44)

was working on the old header, scanning it

[Melody] Re: DEM2POV v1.4 [2320 days 21 hours and 41 minutes ago]

Thu, 5 Dec 2019 08:00:01 GMT

Kauai Project took 1400 character upgrade to the script, smarter program.
see alias deminit,
set a few things, it should fly.

[Melody] Re: DEM2POV v1.4 [2321 days 3 hours and 41 minutes ago]

Thu, 5 Dec 2019 02:00:00 GMT

fixed two mistakes in script
and report remaining file locations
tested menu commands
get latest changes, in working order

[Melody] Re: DEM2POV v1.4 [2321 days 4 hours and 11 minutes ago]

Thu, 5 Dec 2019 01:30:00 GMT

obviously I'm slow. and hindsight is 20/20.
the whole menu, doh

menu status {
  -
  DEM Commands
  .DEM Initialize: deminit
  .Make unzipbat.txt: unzipall
  .DEMPOV Batch Files: dems_batch
  .Read DEM Headers: demHeadRead
  .Sort DEMs: demsort
}

[Melody] Re: DEM2POV v1.4 [2321 days 4 hours and 41 minutes ago]

Thu, 5 Dec 2019 01:00:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> And there is this:
> https://earthexplorer.usgs.gov/
>
> --
> Thomas

thanks if it has DEM files. would be cool.

probably should have waited another a week to post, it's never done.
with bulletproof defaults, it wont error.
reading the program answers all questions.

post any changes to main.c or dems*.mrc -
if two heads aren't better than one, everything is doomed for sure.

Current issue in main.c is a 2-4 degree rotated image, for some DEMs.

[Melody] Re: DEM2POV v1.4 [2321 days 5 hours and 11 minutes ago]

Thu, 5 Dec 2019 00:30:01 GMT

and for the user friendly stuff, add this,

alias deminit {
  %parameters = 0 0 15 0
  %WorkingDir = c:\ftp\dempov\bin
  %proj = untitled
  ; if (!init) program uses defaults
}
menu status {
  -
  DEM Initialize: deminit
}

added project title, which is set with a filename if you dont.
title*.bat files makes more sense.

[Thomas de Groot] Re: DEM2POV v1.4 [2321 days 22 hours and 9 minutes ago]

Wed, 4 Dec 2019 07:32:47 GMT

Op 04/12/2019 om 02:02 schreef Melody:
> http://edc.usgs.gov/geodata/
> 
> can anyone get in?
> 
> This site can’t be reached
> edc.usgs.gov’s server IP address could not be found.
> 
> if only it were that easy for them to go away
> 
> 
> 

And there is this:
https://earthexplorer.usgs.gov/

-- 
Thomas

[Thomas de Groot] Re: DEM2POV v1.4 [2321 days 22 hours and 12 minutes ago]

Wed, 4 Dec 2019 07:29:12 GMT

Op 04/12/2019 om 02:02 schreef Melody:
> http://edc.usgs.gov/geodata/
> 
> can anyone get in?
> 
> This site can’t be reached
> edc.usgs.gov’s server IP address could not be found.
> 
> if only it were that easy for them to go away
> 
> 
> 

Alternatively, there is this:
https://dds.cr.usgs.gov/srtm/version2_1/SRTM3/

-- 
Thomas

[Melody] Re: DEM2POV v1.4 [2322 days and 6 minutes ago]

Wed, 4 Dec 2019 05:35:00 GMT

Niagra county,
only 6,
not normalized,
bias of 0, aligned heights better than default bias.
but Gasport was way off

fine tuned ...
path %PATH%;c:\ftp\dempov\bin
DEMPOV akron.dem akron.tga 0 0 4.5 0 0
DEMPOV barker.dem barker.tga 0 0 5 0 0
DEMPOV gasport.dem gasport.tga 0 0 16 0 0
DEMPOV lyndonville.dem lyndonville.tga 0 0 5 0 0
DEMPOV medina.dem medina.tga 0 0 4.6 0 0
DEMPOV wolcottsville.dem wolcottsville.tga 0 0 4.6 0 0

got enough options,
just depends on the data you have, apparently.

Shasta county and Mount Shasta were 0 0 15 0

[Melody] Re: DEM2POV v1.4 [2322 days 4 hours and 6 minutes ago]

Wed, 4 Dec 2019 01:35:00 GMT

final DEMPOV.exe output is interesting,
4 parameters 0 1 1 0, using default bias,
might be correct usage.

 file gce.tga
  1442401 pixels were written to the file.
 For converted data points:
      MinValue =      0.000 MaxValue =  65535.000

but do the heights align, yet to be tested.

0 0 15 0,
used in previous renders, heights aligned.
with a hefty block underneath.

need more test renders.
all i got so far.

[Melody] Re: DEM2POV v1.4 [2322 days 4 hours and 36 minutes ago]

Wed, 4 Dec 2019 01:05:00 GMT

http://edc.usgs.gov/geodata/

can anyone get in?

This site can’t be reached
edc.usgs.gov’s server IP address could not be found.

if only it were that easy for them to go away

[Melody] Re: DEM2POV v1.4 [2322 days 4 hours and 51 minutes ago]

Wed, 4 Dec 2019 00:50:01 GMT

1 meter Digital Elevation Models (DEMs) - USGS National Map
https://catalog.data.gov

3.4 is the tightest there is, according to google,
of course I dont see any data there. that 3-letter word again.

[Melody] Re: DEM2POV v1.4 [2322 days 5 hours and 11 minutes ago]

Wed, 4 Dec 2019 00:30:00 GMT

webgis page says
USGS 1-Degree Native Format - United States

Resolution: ~90 m, 3 arc-sec
Coverage: Contiguous United States, Hawaii and parts of Alaska
Projection: UTM
Datum: WGS 72
Vertical Units: Meter

AND HOW exactly does it explain the file data at 30 30 1
Vs
3 3 1, not seen there, but in gce.dem, included.

[Melody] Re: DEM2POV v1.4 [2322 days 6 hours and 1 minute ago]

Tue, 3 Dec 2019 23:40:00 GMT

savebuf -s %WorkingDir $+ \sortpov.pov
  e saved to %WorkingDir $+ \sortpov.pov
> better
> user friendly stuff

[Melody] Re: DEM2POV v1.4 [2322 days 6 hours and 11 minutes ago]

Tue, 3 Dec 2019 23:30:00 GMT

add one more line to the sorter, last line, FYI.
good to know.
e saved to $mircdir $+ sortpov.txt

user friendly stuff

[Melody] Re: DEM2POV v1.4 [2322 days 7 hours and 6 minutes ago]

Tue, 3 Dec 2019 22:35:05 GMT

the files at webgis say spatial res 30 30 1, seems there is better by comparison
of the two Grand Canyon files,

3 arc seconds 90 meters World-wide SRTM
1 arc second 30 meters DEM from topo, USA SRTM
1/3 arc second 10 meters DEM from topo
1/9 arc second 3.4 meters Newer DEM from LIDAR

included Grand Canyon said,
[15] spatial resolution:   3 3 1

and all that leaves speculation room for spatial speculation.

[Melody] Re: DEM2POV v1.4 [2322 days 7 hours and 26 minutes ago]

Tue, 3 Dec 2019 22:15:05 GMT

v3 SORTER for Mirc, ungraded more friendly.
no way anyone could easily use v2.
alias goDEMs3 {
  ; 30-meter with 7z.exe 7z.dll in folder or path
  ; http://www.webgis.com/terr_pages/AZ/dem1/coconino.html
  %WorkingDir = c:\ftp\dempov\bin
  ; New instructions
  ; Set %WorkingDir - download zips -- no pasting html to dems.txt
  ; /unzipall   ... make unzip_bat.txt - open and check it. resave as .bat
  ; unzip_bat   ... same-name files exist! a(u)to rename to keep all: u
  %parameters = 0 1 1 0
  ; /dems_batch ... make rename_bat.txt - open and check it. resave as .bat
  ; rename_bat  ... rename DEM files
  ; /dems_batch ... make dem2tga_bat, with renamed DEM files, for tga files
  ; dem2tga_bat ... DEMPOV nelson.dem nelson.tga 0 1 1 0
  demHeadRead
  demsort
}

[Melody] Re: DEM2POV v1.4 [2323 days 6 hours and 51 minutes ago]

Mon, 2 Dec 2019 22:50:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> thanks for this. I used DEM files (from the usgs) mor than 15 years ago
> iirc. I would need to dig deep for my work, or for what is left of it.
> In time (not soon unfortunately) I shall come back to this.
>
> --
> Thomas

hope to find better resolution.
that one site was the only *available data I could find.
..gov is not working for the people, obviously.

[Melody] Re: DEM2POV v1.4 [2323 days 16 hours and 56 minutes ago]

Mon, 2 Dec 2019 12:45:00 GMT

i got time

if normalizing or not, 4 parameters is default bias
hfBias = -elevBounds[0];

[Melody] Re: DEM2POV v1.4 [2323 days 17 hours and 36 minutes ago]

Mon, 2 Dec 2019 12:05:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 02/12/2019 om 11:07 schreef Melody:
> > so if you're going to do DEM, cant be stuck in user mode, one at a time.
> >
> > Code::Blocks project
> > Command line parameters version and the sorter batch maker script for mirc.
> > includes Grand Canyon Elevation at spatial res 3 3 1, not 30.
> >   Example render script
> >
> > not windows? make your own in C. DIY
> >
> >
>
> thanks for this. I used DEM files (from the usgs) mor than 15 years ago
> iirc. I would need to dig deep for my work, or for what is left of it.
> In time (not soon unfortunately) I shall come back to this.
>
> --
> Thomas
youre welcome,
found my mistake,

to batch files, seems a good idea to use default bias,
(you cant see min_elev and enter it, as in user mode)

just remove :
  if (hfType == 1) hfBias = atof(argv[5]);
  else

then you always set default bias with only 4 parameters.
doh. my bad. or let me know if you want the upgrade exe.

[Thomas de Groot] Re: DEM2POV v1.4 [2323 days 17 hours and 49 minutes ago]

Mon, 2 Dec 2019 11:51:59 GMT

Op 02/12/2019 om 11:07 schreef Melody:
> so if you're going to do DEM, cant be stuck in user mode, one at a time.
> 
> Code::Blocks project
> Command line parameters version and the sorter batch maker script for mirc.
> includes Grand Canyon Elevation at spatial res 3 3 1, not 30.
>   Example render script
> 
> not windows? make your own in C. DIY
> 
> 

thanks for this. I used DEM files (from the usgs) mor than 15 years ago 
iirc. I would need to dig deep for my work, or for what is left of it. 
In time (not soon unfortunately) I shall come back to this.

-- 
Thomas

[Melody] DEM2POV v1.4 [2323 days 19 hours and 31 minutes ago]

Mon, 2 Dec 2019 10:10:02 GMT

so if you're going to do DEM, cant be stuck in user mode, one at a time.

Code::Blocks project
Command line parameters version and the sorter batch maker script for mirc.
includes Grand Canyon Elevation at spatial res 3 3 1, not 30.
 Example render script

not windows? make your own in C. DIY

[Melody] DEM2POV v1.3 [2329 days 4 hours and 56 minutes ago]

Wed, 27 Nov 2019 00:45:01 GMT

1.2 by Kirby'96 would only read
[15] spatial resolution:        3.00000,        3.00000,         1.00000
or, that is perhaps "DEM Header Format: Old"

if (spatialResolution[0] != 3.0)
got 0 values, floats not resolving BECAUSE of "inText[20] = 'E';"
     removed them all.

now read mores ... http://www.webgis.com/terr_us1deg.html
DEM Header Format: New
[1&2] Map label: YELLOWSTONE POINT, WY-24000  LAT::   44  0  0.0000 N LONG:: -1
10  0  0.0000 W SCALE:: 24000 (SDTS2DEM v.0.018)
[15] spatial resolution:        30.00000,        30.00000,         1.00000
[15] spatial resolution:        10.00000,        10.00000,         .100000
"Old"
[15] spatial resolution:        3.00000,        3.00000,         1.00000
My question is, what is deltaY supposed be for others, if spaceRes3 is / 3600 ??

[Melody] 3.63 Console [2332 days 23 hours and 51 minutes ago]

Sat, 23 Nov 2019 05:50:00 GMT

povray363con.zip  625,023 bytes
povray.exe 2,029,928 bytes

patches:
Stereoscopic Camera
Motion Blur
Date Time
Glow

[Melody] Re: POV Ray 3.63 [2333 days 3 hours and 41 minutes ago]

Sat, 23 Nov 2019 02:00:00 GMT

one more idiosyncrasy on glow{}

place cursor on glow, and hit F1,
even if you rename megapov.chm
to povray36.chm = F1 doesnt help you.

use the search tab, search glow, it's under effects.
motion_blur is found with F1.
there is no help entry on stereo. not quite on your own tho.

#declare _stereo_ = 0;   //makes L/R frames
// drop composite.exe in file dir and RUN *3d.ini, not this file
#declare stereo_movie = 0; // set to 1 and RUN *3d_mov.ini
#include "stereo_equip.inc" // edit BATCH FILE maker filenames
camera {
#if (_stereo_)
    stereoscopic
    zeroparallax 90
    eyeseparation 1
#end

}

*3d.ini
Post_Frame_Command="composite -stereo %sR.png %sL.png %sA.png"
 ; Post_Scene_Command="composite -stereo %sR.png %sL.png %sA.png"
Post_Frame_Return=I

(but as of win7 .bat file needs admin priv I suspect)

help files don't compress much
Error: Attachment was too big. Allowed are only up to 5120000 bytes!
it was only 4,222,000 - get it on your own.

example glow
#macro charge(p,col,scl)
   glow { type 0 // type 0 | 1 | 2 | 3
              location p
              color rgb col
              size scl
              fade_power 2.5
   }
#end

[Melody] Re: POV Ray 3.63 [2334 days 23 hours and 56 minutes ago]

Thu, 21 Nov 2019 05:45:00 GMT

to make red/blue images, I wanted to include composite.exe, only 188k but that
was when ... now is 3 meg, no dlls. I like that better.

32 bit
https://imagemagick.org/download/binaries/ImageMagick-7.0.9-5-portable-Q16-x86.zip

64 bit
https://imagemagick.org/download/binaries/ImageMagick-7.0.9-5-portable-Q16-x64.zip

no installation needed .. here's the page for EVerYThing
http://www.imagemagick.org/script/download.php

[Melody] Re: POV Ray 3.63 [2335 days 21 hours and 11 minutes ago]

Wed, 20 Nov 2019 08:30:02 GMT

previous was poorly prepared, had to sort archive by date to find latest 3.63,
due to lack of total recall. glow{} IS in both.

two versions povray in this file
#version 3.63 glow{}, motion_Blur{}, stereo camera, Date Time set
#version unofficial megapov 1.21;

megapov help file would not fit 5m limit, so you have to get it, dl megapov.
stereo example, and include files
stereo_equip.inc
megatime.inc

I did remember glow{} being there, memory made me go find it.

again:
uninstall 3.7 -- install 3.6 ( https://www.povray.org/download/index-3.6.php )
place files in bin folder and rename, whichever one youre using, to
pvengine.exe ... or not. can be run as any filename, but other programs call the
known pvengine.exe

Wont put your files in Documents folder;

[Melody] Re: LEGO Library [2338 days 3 hours and 51 minutes ago]

Mon, 18 Nov 2019 01:50:01 GMT

ok I messed up that file. didnt remember one file had it all.
it should have been half that size, sorry.

[Melody] Re: LEGO Library [2338 days 5 hours and 1 minute ago]

Mon, 18 Nov 2019 00:40:01 GMT

here's more stuff to get u going

[Melody] POV Ray 3.63 [2339 days and 51 minutes ago]

Sun, 17 Nov 2019 04:50:02 GMT

Windows 7, and #version 3.7 - F1 Fails !!!!!
I don't know what 3.7 can do, but it's easier to fix the F1
issue by renaming exe files.

two versions povray in this file
#version 3.63 motion blur and stereo camera
#version unofficial megapov 1.21;

uninstall 3.7 -- install 3.6 ( https://www.povray.org/download/index-3.6.php )
place files in bin folder and rename, whichever one youre using, to
pvengine.exe

and it wont put your files in Documents folder or wherever the hell 3.7 puts
them. that sucked, so hated that.

correctly compiled with mingw.

[Melody] LEGO Library [2345 days 8 hours and 26 minutes ago]

Sun, 10 Nov 2019 21:15:01 GMT

dont let it get lost again.

[Thomas de Groot] Catenaries and chains utilities [2362 days 22 hours and 34 minutes ago]

Thu, 24 Oct 2019 07:06:59 GMT

For easier subsequent finding, I bring together here the three utilities 
for making chains and catenaries discussed elsewhere (see initial 
message in povray.newusers: 
https://news.povray.org/povray.newusers/thread/%3Cweb.5daed46f8fb75c41ad6bf02d0%40news.povray.org%3E/

)

1) Lance Purple: Pylon.zip
2) PM 2Ring: Catenary.zip
3) Rob Antonishen: Chain.zip

Additionally, it is always worthwhile to visit the LohmÃ¼ller site: 
http://www.f-lohmueller.de/index.htm

-- 
Thomas

[Sven Littkowski] Re: oh_joy for windows [2460 days 15 hours and 16 minutes ago]

Thu, 18 Jul 2019 14:25:08 GMT

On 09.01.2011 10:18, HexHall wrote:
> I wrote this program with my ancient microsoft windows visual c++ 6.0
> compiler as an updated version of the "hopalong" program from the Sep 198
6
> Scientific American article (I got that issue as part of my ongoing
> subscription-->yes I am that old).  I figured some of the POV community
> might want to use it to make background images, as image_maps, height
> fields, etc. Will post one or two pics on binaries.images later on.  Enjo
y
> 
> Hexhall (formerly pentahall, quadhall, and originally treshall)
>   
> 
> 

Thanks for sharing.

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[And] Re: sky light render [2596 days 23 hours and 46 minutes ago]

Mon, 4 Mar 2019 05:55:01 GMT

I'm proud of my ability. It is really like smoke(with the help of blender). At
least I have known how to simulate the optical process and produce the correct
result. The render speed is slow. So I found another algorithm metropolis light
transport to study.. for the future.

[And] Re: sky light render [2599 days 17 hours and 46 minutes ago]

Fri, 1 Mar 2019 11:55:01 GMT

pure sky

[And] Re: sky light render [2599 days 17 hours and 51 minutes ago]

Fri, 1 Mar 2019 11:50:00 GMT

Another scattering and absorb. The light source and atmosphere is the same on
these three images.

[And] Re: sky light render [2599 days 17 hours and 56 minutes ago]

Fri, 1 Mar 2019 11:45:01 GMT

Only scattering, no absorb

[And] Re: sky light render [2599 days 18 hours and 1 minute ago]

Fri, 1 Mar 2019 11:40:01 GMT

material with scattering and absorb.

[ingo] voro++pov.py [2619 days 11 hours and 18 minutes ago]

Sat, 9 Feb 2019 18:23:08 GMT

A, rather crude, python file to work with Voro++ for creating voronoi 
object / data. It sends an inputfile to Voro++ and then parses its output 
and writes an include file with arrays.

ingo

[And] Re: sky light render [2630 days 23 hours and 1 minute ago]

Tue, 29 Jan 2019 06:40:02 GMT

And This is the Pov-ray version:

using two point lights.

[And] Re: sky light render [2630 days 23 hours and 1 minute ago]

Tue, 29 Jan 2019 06:40:01 GMT

Using df3 file from Pov-ray output.

#declare p_dens =
pigment{
spherical
    color_map{
            [0.22 rgb 0]
            [0.32 rgb 1]
            [1.0 rgb 1]
             }
   scale 4.4
   warp{turbulence .8 omega .7}
}

[And] Re: sky light render [2638 days 15 hours and 31 minutes ago]

Mon, 21 Jan 2019 14:10:01 GMT

This one is rendered by my father's computer, faster than my notebook.

This one shows the bug.

[And] Re: sky light render [2638 days 15 hours and 36 minutes ago]

Mon, 21 Jan 2019 14:05:02 GMT

The lower sun(15 degree above horizon)

[And] Re: sky light render [2638 days 15 hours and 36 minutes ago]

Mon, 21 Jan 2019 14:05:01 GMT

I just want to show the previous images that I rendered with my program.

[ingo] Re: Tool to generate "cube uv mapping" example i... [2654 days 14 hours and 21 minutes ago]

Sat, 5 Jan 2019 15:20:25 GMT

in news:5c0a4279@news.povray.org Lars R. wrote:

> UV mapping

Nice. 
Have to dig a bit, I must have a whole pile of uv map test images made in 
inkscape,

ingo

[jr] Re: df3 tools [2670 days 7 hours and 51 minutes ago]

Thu, 20 Dec 2018 21:50:01 GMT

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.5b43d8aa43fdfea9635cc5ad0@news.povray.org jr wrote:
> > and the SQlite3 extension
>
> Nice. I once tried to stash a big df3 in an R-tree module table. Sqlite
> didn't realy like it :)

tsk, tsk.  :-)

thank you for trying it.  let me know if you encounter problems.


regards, jr.

[ingo] Re: df3 tools [2670 days 13 hours and 39 minutes ago]

Thu, 20 Dec 2018 16:02:39 GMT

in news:web.5b43d8aa43fdfea9635cc5ad0@news.povray.org jr wrote:

> and the SQlite3 extension

Nice. I once tried to stash a big df3 in an R-tree module table. Sqlite 
didn't realy like it :)

ingo

[Lars R ] Tool to generate "cube uv mapping" example image [2683 days 19 hours and 50 minutes ago]

Fri, 7 Dec 2018 09:50:49 GMT

To experiment with the UV mapping I wrote a tiny C++ program that
generate an example image that can be use to illustrate and understand
the "uv_mapping" on boxes/cubes.

Feel free to use and modify it at will. (license: WTFPL 2.0 :-))

Have fun!

		Lars R.

[pascal] Re: ldossantos@groupama-cm.fr [2703 days 9 hours and 37 minutes ago]

Sat, 17 Nov 2018 20:04:34 GMT

On 17/11/2018 16:53, Le_Forgeron wrote:
> Le 17/11/2018 Ã  14:18, pascal a Ã©critÂ :
> 
>> DÃ©solÃ©...Il s'agit bien Ã©videmment d'une erreur.
>> J'ai cherchÃ© Ã  joindre les administrateurs de la liste afin
de le
>> supprimer mais je n'ai pas trouvÃ© oÃ¹ m'adresser...
>> Encore dÃ©solÃ© du bruit.
>> P.
> 
> Si tu as postÃ©/consultÃ© via nntp (groupe de news), ton
logiciel
> d'origine peut faire un "cancel" sur ton propre article.
> 
Merci Ã  vous...
Je ne savais pas si Ã§a pouvait l'effacer de la liste.
Bonne soirÃ©e
P.

[dick balaska] Re: ldossantos@groupama-cm.fr [2703 days 12 hours and 20 minutes ago]

Sat, 17 Nov 2018 17:21:15 GMT

On 11/17/18 8:25 AM, pascal wrote:

> 
> And in english :
> Sorry !...It's obviously a mystake.
> I tried to contact the list admins to remove it but didn't find a way to
> do so...
> Once more, I'm sorry for the noise...
> P.

You used Thunderbird to post the message, so:
1) Highlight the message.
2) In the "Message" menu, select "Cancel Message"
3) *poof*

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[Le Forgeron] Re: ldossantos@groupama-cm.fr [2703 days 13 hours and 47 minutes ago]

Sat, 17 Nov 2018 15:53:57 GMT

Le 17/11/2018 Ã  14:18, pascal a Ã©critÂ :

> DÃ©solÃ©...Il s'agit bien Ã©videmment d'une erreur.
> J'ai cherchÃ© Ã  joindre les administrateurs de la liste afin de
le
> supprimer mais je n'ai pas trouvÃ© oÃ¹ m'adresser...
> Encore dÃ©solÃ© du bruit.
> P.

Si tu as postÃ©/consultÃ© via nntp (groupe de news), ton logiciel
d'origine peut faire un "cancel" sur ton propre article.

[pascal] Re: ldossantos@groupama-cm.fr [2703 days 16 hours and 16 minutes ago]

Sat, 17 Nov 2018 13:25:04 GMT

On 17/11/2018 14:18, pascal wrote:
> On 17/11/2018 08:50, Thomas de Groot wrote:
>> On 16-11-2018 19:57, pascal wrote:
>>> Bonjour Mme Dos Santos
>>>
>>> Vous vous Ã©tiez acquittÃ© avec diligence et gentillesse de
mon 
>>> sinistre (Sinistre 2018569966).
>>>
>>> Si je ne craignais pas d'abuser de cette gentillesse j'oserais vous 
>>> demander s'il est possible que vous m'envoyiez la confirmation de ma 
>>> souscription Ã  une assurance multi risques habitation auprÃ¨s
de vous, 
>>> confirmation que, trÃ¨s intelligemment, aprÃ¨s de multiples
Ã©changes 
>>> croisÃ©s entre vous, leur assurance et l'agence immobiliÃ¨re
chargÃ©e de 
>>> la gestion locative, cette derniÃ¨re ne cesse de me demander...
>>>
>>> En vous remerciant par avance,
>>>
>>> Je vous souhaite une bonne semaine.
>>>
>>> Pascal Gosse
>>
>>
>> Bonjour Pascal,
>>
>> J'espÃ¨re que ce message ne soit qu'une copie et que l'original ait 
>> bien Ã©tÃ© reÃ§u par son destinataire. Nous ne
connaissons pas hÃ©las de 
>> madame Dos Santos Ã  l'intÃ©rieur du groupe de
crÃ©ation virtuelle 
>> POV-Ray. :-)
>>
>> Salutations,
>>
> 
> DÃ©solÃ©...Il s'agit bien Ã©videmment d'une erreur.
> J'ai cherchÃ© Ã  joindre les administrateurs de la liste afin de
le 
> supprimer mais je n'ai pas trouvÃ© oÃ¹ m'adresser...
> Encore dÃ©solÃ© du bruit.
> P.

And in english :
Sorry !...It's obviously a mystake.
I tried to contact the list admins to remove it but didn't find a way to 
do so...
Once more, I'm sorry for the noise...
P.

[pascal] Re: ldossantos@groupama-cm.fr [2703 days 16 hours and 22 minutes ago]

Sat, 17 Nov 2018 13:18:49 GMT

On 17/11/2018 08:50, Thomas de Groot wrote:
> On 16-11-2018 19:57, pascal wrote:
>> Bonjour Mme Dos Santos
>>
>> Vous vous Ã©tiez acquittÃ© avec diligence et gentillesse de mon
sinistre 
>> (Sinistre 2018569966).
>>
>> Si je ne craignais pas d'abuser de cette gentillesse j'oserais vous 
>> demander s'il est possible que vous m'envoyiez la confirmation de ma 
>> souscription Ã  une assurance multi risques habitation auprÃ¨s
de vous, 
>> confirmation que, trÃ¨s intelligemment, aprÃ¨s de multiples
Ã©changes 
>> croisÃ©s entre vous, leur assurance et l'agence immobiliÃ¨re
chargÃ©e de 
>> la gestion locative, cette derniÃ¨re ne cesse de me demander...
>>
>> En vous remerciant par avance,
>>
>> Je vous souhaite une bonne semaine.
>>
>> Pascal Gosse
> 
> 
> Bonjour Pascal,
> 
> J'espÃ¨re que ce message ne soit qu'une copie et que l'original ait bien 
> Ã©tÃ© reÃ§u par son destinataire. Nous ne connaissons
pas hÃ©las de madame 
> Dos Santos Ã  l'intÃ©rieur du groupe de crÃ©ation
virtuelle POV-Ray. :-)
> 
> Salutations,
> 

DÃ©solÃ©...Il s'agit bien Ã©videmment d'une erreur.
J'ai cherchÃ© Ã  joindre les administrateurs de la liste afin de
le 
supprimer mais je n'ai pas trouvÃ© oÃ¹ m'adresser...
Encore dÃ©solÃ© du bruit.
P.

[Thomas de Groot] Re: ldossantos@groupama-cm.fr [2703 days 21 hours and 51 minutes ago]

Sat, 17 Nov 2018 07:50:14 GMT

On 16-11-2018 19:57, pascal wrote:
> Bonjour Mme Dos Santos
> 
> Vous vous Ã©tiez acquittÃ© avec diligence et gentillesse de mon
sinistre 
> (Sinistre 2018569966).
> 
> Si je ne craignais pas d'abuser de cette gentillesse j'oserais vous 
> demander s'il est possible que vous m'envoyiez la confirmation de ma 
> souscription Ã  une assurance multi risques habitation auprÃ¨s
de vous, 
> confirmation que, trÃ¨s intelligemment, aprÃ¨s de multiples
Ã©changes 
> croisÃ©s entre vous, leur assurance et l'agence immobiliÃ¨re
chargÃ©e de la 
> gestion locative, cette derniÃ¨re ne cesse de me demander...
> 
> En vous remerciant par avance,
> 
> Je vous souhaite une bonne semaine.
> 
> Pascal Gosse


Bonjour Pascal,

J'espÃ¨re que ce message ne soit qu'une copie et que l'original ait bien 
Ã©tÃ© reÃ§u par son destinataire. Nous ne connaissons
pas hÃ©las de madame 
Dos Santos Ã  l'intÃ©rieur du groupe de crÃ©ation
virtuelle POV-Ray. :-)

Salutations,

-- 
Thomas

[pascal] ldossantos@groupama-cm.fr [2704 days 10 hours and 43 minutes ago]

Fri, 16 Nov 2018 18:57:53 GMT

Bonjour Mme Dos Santos

Vous vous Ã©tiez acquittÃ© avec diligence et gentillesse de mon
sinistre 
(Sinistre 2018569966).

Si je ne craignais pas d'abuser de cette gentillesse j'oserais vous 
demander s'il est possible que vous m'envoyiez la confirmation de ma 
souscription Ã  une assurance multi risques habitation auprÃ¨s de
vous, 
confirmation que, trÃ¨s intelligemment, aprÃ¨s de multiples
Ã©changes 
croisÃ©s entre vous, leur assurance et l'agence immobiliÃ¨re
chargÃ©e de la 
gestion locative, cette derniÃ¨re ne cesse de me demander...

En vous remerciant par avance,

Je vous souhaite une bonne semaine.

Pascal Gosse

[And] Re: sky light render [2706 days 17 hours and 6 minutes ago]

Wed, 14 Nov 2018 12:35:00 GMT

This diagram calculates complete condition.(no reduce coefficient)

[And] Re: sky light render [2706 days 17 hours and 11 minutes ago]

Wed, 14 Nov 2018 12:30:01 GMT

Rendering cloud needs more time than smoke because the internal scattering in
cloud is very much. It seldom absorb light. So the high level scattering is
frequent.

The attached diagram is about the spectral radiance(light strength) vs level.

first level collect most light because of the sky part of the image. The
scattering of sky is much weak than cloud. Another point is that after level 4 I
using reduce coefficient to calculate the cloud as an approximate. If calculate
complete condition(no approx.) the high level are even more important.

[And] Re: sky light render [2708 days 2 hours and 36 minutes ago]

Tue, 13 Nov 2018 03:05:01 GMT

Stephen <mca### [at] aolcom> wrote:
> On 10/11/2018 13:20, And wrote:
> > I will release it when it is okay. At least one year.
> >
>
> Your time frame is a bit of a disappointment. :-(
It is rendered by my notebook, using 3 thread.
That's true. But After these tests It will improve(I guess about 2x).



> It is interesting that you are incorporating df3s into it. :-)
Uh huh


>
> <Aside>
> Have you seen, Oosawa 4D Volume Viewer?
> http://qcganime.web.fc2.com/OOSAWA/oosawaE.html

No. I never heard it.


>
> One interesting feature is the program can mesh-ify df3s and export them
> as mesh2 or obj.
> Unfortunately (for me) the help file is in Japanese.
>
>
Not bad


>
> --
>
> Regards
>      Stephen

[Stephen] Re: sky light render [2709 days 18 hours and 11 minutes ago]

Sun, 11 Nov 2018 11:30:19 GMT

On 11/11/2018 11:09, Stephen wrote:
> One interesting feature is the program can mesh-ify df3s and export them 
> as mesh2 or obj.

Forgot to mention that he calls it an isosurface. and the export for 
mesh2 is faulty as it includes a trailing comma at the end of each section.

-- 

Regards
     Stephen