povray.programming message digest

[William F Pokorny] Re: building povray on mac [93 days 20 hours and 35 minutes ago]

Sat, 3 Jan 2026 20:23:04 GMT

On 1/3/26 12:15, kurtz le pirate wrote:
> In which file(s) should this option be added?

Something like:

./configure COMPILED_BY="wfp" CXXFLAGS="-fno-finite-math-only"

should work to add the compiler flag for official POV-Ray source releases.

Bill P.

[kurtz le pirate] Re: building povray on mac [93 days 23 hours and 42 minutes ago]

Sat, 3 Jan 2026 17:15:47 GMT

On 03/01/2026 17:09, William F Pokorny wrote:
> On 1/2/26 10:59, kurtz le pirate wrote:
>> Not everything is perfect, but POV-Ray seems to be working except 
>> that... when I try to render I get a "empty" image with only the 
>> background color and the output file has been successfully created.
> 
> The blank render is one of a few bad results of newer g++ versions 
> changing the fast-math flag behavior. While running the configure script 
> add the additional flag mentioned below:
> 
> "Those using g++ compiler version 13 or later must add the compiler flag 
> -fno-finite-math-only, if using the flag -ffast-math."

* Firstly: Thank you for your reply.



* Secondly: So this problem is known. I feel better.



* Finally: I tried adding the -fno-finite-math-only option in several 
files (where CXXFLAGS=... ), but it is not taken into account. In the 
end, I still have:

povray --V
...
Compiler flags: -pipe -Wno-multichar -Wno-write-strings
                 -Wsuggest-override -O3 -ffast-math
                 -march=native -pthread

no /-fno-finite-math-only/



In which file(s) should this option be added?

./configure does not seem to accept this option,
or I did not know how to do it :(





-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: building povray on mac [94 days and 49 minutes ago]

Sat, 3 Jan 2026 16:09:04 GMT

On 1/2/26 10:59, kurtz le pirate wrote:
> Not everything is perfect, but POV-Ray seems to be working except 
> that... when I try to render I get a "empty" image with only the 
> background color and the output file has been successfully created.

The blank render is one of a few bad results of newer g++ versions 
changing the fast-math flag behavior. While running the configure script 
add the additional flag mentioned below:

"Those using g++ compiler version 13 or later must add the compiler flag 
-fno-finite-math-only, if using the flag -ffast-math."

Bill P.

[kurtz le pirate] building povray on mac [95 days and 59 minutes ago]

Fri, 2 Jan 2026 15:59:05 GMT

Best wishes for this new year, which is off to a funny start for me.


After my tests on Ubuntu, I decided to compile POVRay on MacOS Sequoia 
(15.7.3).


I get sources here : https://github.com/POV-Ray/povray
I installed the libraries with brew.

Some information about the result:

 > povray -version
POV-Ray 3.8.0-alpha.unofficial

This is an unofficial version compiled by:
  kurtz le pirate <kur### [at] freefr>
  The POV-Ray Team is not responsible for supporting this version.

Copyright 1991-2019 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions.  There is 
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

Built-in features:
   I/O restrictions:          disabled
   X Window display:          disabled
   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
   Unsupported image formats: openexr

Compilation settings:
   Build architecture:  x86_64-apple-darwin24.6.0
   Built/Optimized for: x86_64-apple-darwin24.6.0 (using -march=native)
   Compiler vendor:     gnu
   Compiler version:    g++ 17.0.0
   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
                        -Wsuggest-override -O3 -ffast-math
                        -march=native -pthread

Not everything is perfect, but POV-Ray seems to be working except 
that... when I try to render I get a "empty" image with only the 
background color and the output file has been successfully created.

Tested with several standard 3.8 scenes and multiple file formats with 
this command line:

	povray fractal1.pov +W800 +H600 +FN8

No error on output console.

Others info about lib with povray -? command:

Support libraries used by POV-Ray:
   ZLib 1.2.12, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
   LibPNG 1.6.53, Copyright 1998-2012 Glenn Randers-Pehrson
   LibJPEG 8, Copyright 1991-2016 Thomas G. Lane, Guido Vollbeding
   LibTIFF 4.7.1, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
   Boost 1.90, http://www.boost.org/





Does anyone have any idea what might be happening and
can give me a clue as to how to resolve this issue?

ðŸ¤ª




-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: POV-Ray as WASM module [145 days and 17 minutes ago]

Thu, 13 Nov 2025 16:40:45 GMT

On 12/11/2025 18:50, Bald Eagle wrote:
> yesbird wrote:
>   The same
>> thing are possible with other instruments, but most of them use
>> Python, which I don't like.
> 
> Yeah - I didn't like Python much when I had to use it for something.

I respect everyone's choice, but Python is a very unpleasant language.




> What do you think of this:
> https://netbeans.apache.org/tutorial/main/tutorials/nbm-povray-1/

Hum... what a complicated factory!




-- 
kurtz le pirate
compagnie de la banquise

[yesbird] Re: POV-Ray as WASM module [145 days 2 hours and 40 minutes ago]

Thu, 13 Nov 2025 14:17:36 GMT

On 12/11/2025 20:50, Bald Eagle wrote:
> What do you think of this:
> https://netbeans.apache.org/tutorial/main/tutorials/nbm-povray-1/

Honestly, I think that both are outdated - Net Beans and Pov-ray :).
--
YB

[Bald Eagle] Re: POV-Ray as WASM module [145 days 23 hours and 3 minutes ago]

Wed, 12 Nov 2025 17:55:00 GMT

yesbird wrote:
 The same
> thing are possible with other instruments, but most of them use
> Python, which I don't like.

Yeah - I didn't like Python much when I had to use it for something.

What do you think of this:
https://netbeans.apache.org/tutorial/main/tutorials/nbm-povray-1/

[yesbird] Re: POV-Ray as WASM module [147 days 12 hours and 44 minutes ago]

Tue, 11 Nov 2025 04:13:25 GMT

On 10/11/2025 21:38, Bald Eagle wrote:
> Thank you, Sergei.
> I'm really glad that you joined us and are also thinking about these things -
> and DOING them.

Well, but before doing something I am prefer thinking :).

> 
> I had one of the demonic AI's look it over and give me its summary, because
> blindly picking my way through tens of thousands of lines of opaque code was
> beyond my present capabilities.
Thanks, Bill, for sharing the results of your experiments with AI, but
unfortunately they will not help us anyway. Code is too complicated
for AI at present time besides the noise it can not give us anything.
Let's wait 10-20 years, and then maybe ...

The main question for me now is it worth to mess with ray tracing, while
we have WebGL/WebGPU now that's enough for most tasks ?

I guess POV-Ray is very good for math experiments, like fractal
rendering, blobs interactions, etc. to produce unusual effects
and artifacts (attached) that can be treated as modern art. The same
thing are possible with other instruments, but most of them use
Python, which I don't like.
-- 
YB

[Bald Eagle] Re: POV-Ray as WASM module [147 days 20 hours and 53 minutes ago]

Mon, 10 Nov 2025 20:05:00 GMT

When I was actively working on reproducing Steven Marschner's
"Simulating the structure and texture of solid wood", I noticed that he used
the Mitsuba renderer.
https://www.mitsuba-renderer.org/

So, it seemed to me that if it was easy for his team to add the custom BRDF's
and other parts of the wood texture to the renderer, then that would be
something we'd be seriously interested in drawing inspiration from.

Now, granted, the AI word-soup is awash with generalities, however coupled with
the Mitsuba github repository, it might give us concrete ideas about some
actionable plans for refactoring POV-Ray.

"can you provide an overview of how the mitsuba renderer works?
https://github.com/mitsuba-renderer/mitsuba3 "


architecture and core systems:

---

## 🏗️ High-Level Architecture

**Mitsuba 3** is a modular, research-oriented renderer implemented in C++17,
centered around the **Dr.Jit** Just-In-Time (JIT) compiler. It supports multiple

### Key Components:
- **Core System**: Fundamental math types, structures, utilities.
- **Build System**: Manages plugins and selectable variants via CMake .
- **Plugins**: Encapsulate BSDFs, shapes, emitters, sensors, integrators.
- **Python Bindings**: Full-featured Python interface and JIT compilation,
enabling dynamic scripting and differentiability .

---

## 🌳 Scene Representation

The **Scene** class serves as a unified container for geometry, materials,
emitters, sensors, media, and their acceleration structures .

### Responsibilities:
- Hosts collections of shapes, emitters, sensors, media.
- Functions for ray intersection and visibility testing:
  - `ray_intersect()`, `ray_test()`, and `ray_intersect_preliminary()` for
different use cases .
- Works with multiple acceleration backends (CPU KD-tree, Embree; GPU OptiX) .

---

## 🔦 Rendering Pipeline

The core rendering workflow comprises the following:

1. **Integration**: Integrators perform Monte Carlo sampling and solve light
transport.
2. **Sampling & Ray Generation**: Samplers and sensors generate rays through
pixels.
3. **Ray Tracing**: Ray-scene intersections via the Scene class.
4. **Shading**: BSDFs handle surface-material responses; emitters add radiance.
5. **Accumulation**: Results are aggregated in a Film/ImageBlock and
post-processed .

### Notable Integrator Types:
- `PathIntegrator`, `VolumetricPathIntegrator`, `DirectIntegrator`,
`AOVIntegrator`, etc. .

---

## 🛰️ Ray Tracing Subsystem

- The **Scene** class provides core intersection queries:
  - Full surface interactions (`SurfaceInteraction3f`).
  - Visibility-only checks (`ray_test()`).
  - Preliminary intersection data (`PreliminaryIntersection3f`) .
- Supports SIMD/vectorized execution and mask-based coherence for performance .

---

## 🧩 Plugin & Variant System

- **Plugins** cover a wide array of BSDFs, media, sensors, etc., each separately
compiled.
- **Variants** enable multiple execution modes: CPU vs. GPU, RGB vs. spectral,
differentiable rendering, etc. .

---

## ✅ Summary Diagram

```text
[Dr.Jit Variant System]
      ↓
  ┌─────────┐

┌────────────┐
  │Parser & │        │Plugins     │
  │Scene    │── feeds → BSDFs,     │
  │System   │        │Shapes,      │
  └─────────┘
      │Emitters,    │
        │            │Sensors, etc.
        ↓              ↓
[Compose Scene Object: geometry, materials, lights, cameras, media]
        ↓
[Scene: acceleration + intersection API]
        ↓
Integrators + Samplers + Sensors
        ↓
      [Ray Tracing]
        ↓
    [Shading & Sampling]
        ↓
     [Rendering Output]
        ↓
Film/ImageBlock → Image File
```

---

## 💡 Why it Inspires Refactoring

- **Clear modularization**: Core scene, plugins, and rendering separated.
- **Abstraction layer**: Normalized scene description before processing.
- **Extensibility**: Plugins and variants enable flexible composition.


1. Introduce **variant/backend system** for flexibility (CPU/GPU, plain vs.
differentiable).
2. Separate **scene representation** from raytracing entirely.
3. Organize features as **plugins**, e.g. SDL parser, BSDFs, shapes,
integrators.
4. Provide **clear interfaces** between parsing, scene assembly, raytracing, and
image output.

---

This modular, plugin-centric organization combined with variant-based
flexibility makes Mitsuba 3 a strong reference model.

[Bald Eagle] Re: POV-Ray as WASM module [147 days 21 hours and 13 minutes ago]

Mon, 10 Nov 2025 19:45:00 GMT

can you compare the structure of povray's source code to that of other
raytracers and summarize the similarities and differences that might inspire a
concrete plan for refactoring povray's codebase to separate the parser from the
other raytracing functions?


Copilot said:

Below is a comparison of POV‑Ray’s structure with other notable ray
tracers—PBRT and LuxCoreRender—highlighting similarities and differences.
These
insights can directly guide a concrete refactor plan to cleanly separate parsing
from rendering responsibilities in POV‑Ray.

🧭 POV‑Ray Architecture
Monolithic structure: Parser, scene, and renderer modules are tightly interwoven
under source/, with parser directly including core renderer headers.
github
+1

Parser builds "final" core objects: Scene description parser creates instances
like core::lightsource, boundingsphere, etc., effectively merging parsing and
rendering payload construction.
github
+1

No abstract scene interface: There is no neutral, shared representation (scene
graph) between parsing and raytracing—the parser itself assembles
renderer-specific structures.

🧱 PBRT (Physically Based Rendering Toolkit)
Clear parser-render separation:

parser.cpp reads scene files and invokes methods in a ParserTarget interface.
pbr-book
+1
BasicSceneBuilder, implementing ParserTarget, translates parsing events into a
neutral scene format, independent of rendering.
pbr-book
Modular architecture:

Parsing → abstract operations → scene builder → later delivery
to rendering engine.
The rendering system consumes scene data only through this abstract interface.
Advantages:

Dramatically easier to test parsing separately.
Parsers don’t require rendering headers or objects.
Enables preview tools, scene validation, and modular pipeline extensibility.
⚙️ LuxCoreRender
Explicit modular structure:

luxparser/: scene description parser module.
slg/: scene layout generator (scene object assembly).
luxrays/: low-level raytracing engine.
luxcore/: high-level API layering.
deepwiki
+2
Strict role separation:

Parsers feed into scene structure objects.
Raytracer consumes the high-level scene structure without any parser
dependencies.
Interfaces provide clear boundaries and prevent coupling.
Benefits:

Enables multiple front-ends (e.g., Blender exporter).
Clean CI with parser tests, unit tests, and renderer benchmarks.
📊 Comparison Overview
Feature POV‑Ray PBRT LuxCoreRender
Parser + Renderer coupling Tight (direct includes) ✅ Loose via
ParserTarget interface ✅ Loose via scene modules
Abstract scene rep. ❌ None—parsing builds core types ✅ Yes, neutral
scene builder ✅ Yes, slg layer
Parser testability Low—coupled to renderer High—parser independent
High—parser
modular
Front-end flexibility Low—SDL only Parser-based plugins via interface
High—SDL,
API, exporter
CI/test modularity Poor—hard to isolate tests Good—parser and builder tested
separately Good—distinct parser, API, renderer
🔧 Concrete Recommendations for POV‑Ray Refactoring
Extract ParserTarget-like interface:

Define abstract methods (Shape(), Light(), Camera(), etc.) instead of
constructing core objects directly.
Introduce SceneBuilder layer:

Implement new SceneBuilder that receives parser events and constructs an
intermediate, neutral graph (objects, lights, cameras).
Create Core-Adapter layer:

Convert SceneBuilder output into core:: rendering types such as LightingSource,
RenderableObject, etc.
Decouple parser from core headers:

parser/ should only include parser and scenebuilder headers; it must not depend
on core/.
Refactor core/ to consume only neutral scene format:

Move all rendering initialization to accept the neutral structure.
Modular testing strategy:

Parser: syntactic/semantic SDL tests invoking parser against various inputs.
SceneBuilder: tests checking neutral graph correctness.
Adapter: verifying translation to renderer types.
Renderer: test rendering of minimal scenes and scene consistency semantics.
✅ Steering Toward a Targeted Refactor
Initial step: define the IParserTarget interface for parser outputs.
Next: build SceneBuilder implementing this interface to collect parsed elements.
Then: implement an adapter to convert to core types.
Finally: adjust core renderer to consume adapter-produced objects, removing all
SDL-specific includes from core/.
This roadmap mimics PBRT and LuxCore’s layered design—ensuring parser
independence, modularity, testability, and flexibility for future front-ends.

[Bald Eagle] Re: POV-Ray as WASM module [147 days 21 hours and 23 minutes ago]

Mon, 10 Nov 2025 19:35:00 GMT

No idea if any of this mechanical parroting will make any sense or yield fruit,
but I have a little time before heading out for the night.

"Show a code sketch of the decoupling and Suggest tests for each module"

Here’s a code sketch that shows how to decouple the parser, scene graph, and
raytracer in POV-Ray, followed by test suggestions for each module.

Code Sketch: Modular Decoupling
1. SceneGraph Module (Neutral Representation)

// scenegraph/Scene.h
#pragma once
#include <vector>
#include <memory>
#include "Object.h"
#include "Camera.h"
#include "Light.h"

class Scene {
public:
    std::vector<std::shared_ptr<Object>> objects;
    std::vector<std::shared_ptr<Light>> lights;
    std::shared_ptr<Camera> camera;

    void AddObject(std::shared_ptr<Object> obj);
    void AddLight(std::shared_ptr<Light> light);
    void SetCamera(std::shared_ptr<Camera> cam);
};


2. Parser Module (No Rendering Dependencies)

// parser/SceneParser.h
#pragma once
#include <string>
#include "../scenegraph/Scene.h"

class SceneParser {
public:
    static std::shared_ptr<Scene> ParseFromFile(const std::string& filename);


3. Adapter Module (SceneGraph → Core Raytracer)

// adapter/SceneAdapter.h
#pragma once
#include "../scenegraph/Scene.h"
#include "../core/RenderScene.h"

class SceneAdapter {
public:
    static std::shared_ptr<RenderScene> ConvertToRenderScene(const
std::shared_ptr<Scene>& scene);
};

4. Raytracer Module (No Parser Dependencies)

// core/RenderScene.h
#pragma once
#include <vector>
#include "RenderableObject.h"
#include "LightSource.h"
#include "Camera.h"

class RenderScene {
public:
    std::vector<RenderableObject> renderables;
    std::vector<LightSource> lights;
    Camera camera;

    void Render();
};

 Suggested Tests for Each Module
🔹 Parser Module


Unit Tests

Parse valid scene file → returns correct SceneGraph structure.
Parse invalid syntax → throws descriptive error.
Parse edge cases (empty file, nested macros, etc.).



Mock Tests

Mock file input and assert SceneGraph output structure.




🔹 SceneGraph Module


Unit Tests

Add/remove objects and lights.
Validate camera assignment.
Ensure deep copies or shared_ptrs behave correctly.



Integration Tests

Construct a Scene manually and verify structure.




🔹 Adapter Module


Unit Tests

Convert SceneGraph with known contents → RenderScene with expected
renderables.
Handle missing camera or lights gracefully.



Mock Tests

Mock SceneGraph and assert correct RenderScene output.




🔹 Raytracer Module


Unit Tests

RenderScene::Render() with minimal scene → produces image buffer.
Test bounding volume hierarchy, intersection logic, shading.



Performance Tests

Render large scenes and measure frame time.

[Bald Eagle] Re: POV-Ray as WASM module [147 days 21 hours and 28 minutes ago]

Mon, 10 Nov 2025 19:30:00 GMT

"Can you identify where parsing, scene description, and raytracing get
interwined in the povray source code https://github.com/POV-Ray/povray and
suggest methods to separate them?"

Here's how parsing, scene description, and raytracing are intertwined in the
POV-Ray codebase, along with suggestions for separating them into cleaner,
modular layers:

---

## 📦 Where Parsing, Scene Description & Raytracing Intersect

### 1. **Parsing Initiates Scene Construction**
- The parsing pipeline is implemented in **source/parser/**:
- `scanner.cpp` and `rawtokenizer.cpp` handle **lexical analysis**,
- `parser.cpp`, `parser_expressions.cpp`, etc., build a detailed **scene
representation** (objects, materials, lights, cameras) in memory .

### 2. **Parser Pulls in Raytracing Code**
- `parser.cpp` directly includes raytracing and rendering headers like:
```cpp
#include "core/lighting/lightsource.h"
#include "core/bounding/boundingsphere.h"
```
This indicates parsing is aware of and uses classes from the core rendering
engine .

### 3. **Scene Graph & Core Raytracing Tied Together**
- As parser builds the scene graph (objects, primitives), it instantiates core
structures like light sources and bounds, which are immediately used by the
raytracer.
- This blending makes it hard to swap or reuse the scene representation
independently of rendering.

---

## 🛠 Suggestions for Modular Separation

### A. **Isolate Parsing into a Dedicated API Layer**
- Extract parsing into a standalone module exposing a clean interface, e.g.:
```cpp
Scene *ParseScene(const std::string &filename);
```
- Internally use parser/scanner/tokenizer, but externally depend only on a
minimal scene structure.

### B. **Define a Neutral Scene Representation (“Scene Graph”)**
- Create an independent data model—objects, materials, transforms—decoupled
from
rendering abstractions.
- Adapt parser to build this neutral graph.
- Develop adapter layers to feed core raytracer components from this graph.

### C. **Use Adapter Patterns to Insert Decoupling Layers**
1. **Parser → SceneGraph Adapter**
- Parser outputs SceneGraph objects, not `core::lightsource`.
2. **SceneGraph → Raytracer Adapter**
- Convert graph nodes into permanent raytracer types within a separate
module.
- Benefits: easier to reuse graph for other backends (e.g. viewport preview,
real-time path tracing).

### D. **Decouple Symbol Table & Expression Evaluation**
- Detach the parser’s symbol and function evaluation from rendering logic.
- Implement two roles:
- **Compile-time AST** building,
- **Runtime evaluator** invoked during rendering, possibly embedded in scene
description rather than renderer.

### E. **Refactor Code Responsibilities**
- Maintain clear boundaries:
- **Parser module**: handles parsing, tokenization, AST building.
- **Scene builder**: constructs neutral scene graph.
- **Raytracer**: consumes scene graph for rendering.
- Requires removal of `#include` dependencies in parser on core/light and
bounding headers.

---

## ✅ Summary of Actions

| Layer | Responsibilities | Proposed
Refactoring |
|------------------|------------------------------------------------|-----------------------|
| **Parser** | Lexing, parsing, AST construction | Outputs
to SceneGraph interface |
| **SceneGraph** | Neutral representation of objects and settings | No
rendering dependencies |
| **Adapters** | Convert SceneGraph to Core types | One
directional mapping layer |
| **Raytracer** | Rendering based on core objects | Independent
from parser |

This structure isolates parsing, scene representation, and raytracing into
separate, testable modules—improving maintainability and enabling reuse.

---

[Bald Eagle] Re: POV-Ray as WASM module [147 days 22 hours and 18 minutes ago]

Mon, 10 Nov 2025 18:40:00 GMT

yesbird wrote:
> I have an idea how to combine web interface and ray tracing calculations
> using the WASM technology:
> https://webassembly.org/. With a WASM it will be possible to use POV-Ray
> API from Javascript/Typescript and the scene can be stored in JSON
> format.
>
> Having raytracing right inside the browser will open the way for
> creating online editor with many pleasant features, such as spline
> editor, for example:
> https://threejs.org/examples/?q=spline#webgl_geometry_spline_editor
>
> I know this assumes a huge amount of work and before diving into this
> inferno, I would like to ask you about possible approaches to start
> with. If I understand well from reading previous posts about related
> refactoring, the main problem is separating a scene description and
> tracing parts from the parser.
>
> Could you please point me to the modules I should examine first of all
> to create a work plan ?
> --
> YB

Thank you, Sergei.
I'm really glad that you joined us and are also thinking about these things -
and DOING them.

I had one of the demonic AI's look it over and give me its summary, because
blindly picking my way through tens of thousands of lines of opaque code was
beyond my present capabilities.

https://news.povray.org/povray.pov4.discussion.general/thread/%3Cweb.6900faee20e0e8051af05c025979125%40news.povray.org%
3E/

(I can keep hammering on this, is we think we can assemble the breadcrumbs it
drops into a map...)

I know that Chris Cason mentioned that he had some plans of his own, so maybe he
might chime in on this.

If there's some way to scan through the old newsgroup posts to get a summary of
what clipka said about disentangling the parser from the raytracer, then that's
an avenue I'd explore as well.  I think Jim Henderson has some sort of fu that
applies in that area.

- BW

[yesbird] POV-Ray as WASM module [148 days 15 hours and 56 minutes ago]

Mon, 10 Nov 2025 01:01:32 GMT

I have an idea how to combine web interface and ray tracing calculations
using the WASM technology:
https://webassembly.org/. With a WASM it will be possible to use POV-Ray
API from Javascript/Typescript and the scene can be stored in JSON
format.

Having raytracing right inside the browser will open the way for
creating online editor with many pleasant features, such as spline
editor, for example:
https://threejs.org/examples/?q=spline#webgl_geometry_spline_editor

I know this assumes a huge amount of work and before diving into this
inferno, I would like to ask you about possible approaches to start
with. If I understand well from reading previous posts about related
refactoring, the main problem is separating a scene description and
tracing parts from the parser.

Could you please point me to the modules I should examine first of all
to create a work plan ?
--
YB

[Bald Eagle] Re: "Clean" debugging [158 days 14 hours and 33 minutes ago]

Fri, 31 Oct 2025 02:25:00 GMT

Worked it out by hand.
Tested.
Works for all but the edge cases where X and Z are 0.
Fair notice: There's a weird hack or two in there.

:)

#declare MA_Deg2Vector_RA_Offset = 180;
// Forward: (RA, Dec, Radius) -> <x, y, z>


#local E = 1E-6;

#macro Sign (N)
 select (N, -1, 0, 1)
#end

#macro MA_Deg2Vector (S_RA, S_Dec, S_Radius)
 #local S_RA = S_RA + MA_Deg2Vector_RA_Offset;
 #local S_Rect = radians(S_RA);

 #local S_Dec = S_Dec + 180;
 #local S_DecRad = radians(S_Dec);
 #local S_DecRad = S_DecRad/2;

 #local S_X = S_Radius * sin(S_DecRad) * cos(S_Rect);
 #local S_Y = S_Radius * cos(S_DecRad);
 #local S_Z = S_Radius * sin(S_DecRad) * sin(S_Rect);

 #local V_Out = <S_X, -S_Y, S_Z>;
 V_Out
#end

#macro MA_Vector2Deg (V_In)
 // Undo the original Y inversion
 #local S_X =  V_In.x;
 #local S_Y = -V_In.y;
 #local S_Z =  V_In.z;



 #local Radius = sqrt(S_X*S_X + S_Y*S_Y + S_Z*S_Z);

 // Handle the degenerate zero-length vector
 #if (Radius < 1e-12)
  #local Result = <0, 0, 0>;
 #else


 //#if (abs(S_Z) < E) S_Z = 0 #end

  #local PreDecRad = S_Y / Radius;

  // Clamp for numeric safety
  #local PreDecRad = max (min (PreDecRad, 1), -1);

  #local DecRad1 = acos (PreDecRad);
  #local DecRad = DecRad1 * 2;
  #local Dec = degrees (DecRad);
  #local Dec = Dec - 180;

  // Try to fix edge cases
  //====================================================
  #if (abs(S_X) < E)
   #local FF = E;
   #local S_X2 = FF*Sign(S_X);
   #local S_Y2 = S_Y + FF*Sign(S_X);
   #local S_Z2 = FF*Sign(S_X);
   #local PreDecRad = S_Y2 / Radius;
   #local PreDecRad = max (min (PreDecRad, 1), -1);
   #local DecRad1 = acos (PreDecRad);
  #else
   #local S_X2 = S_X;
   #local S_Y2 = S_Y;
   #local S_Z2 = S_Z;
  #end
  //====================================================

  #local SinDecRad1 = sin (DecRad1);


  #if (abs(SinDecRad1) < E)
   #local SinDecRad1 = 1;
  #end

  #local PreRect = S_Z2 / (Radius * SinDecRad1);
  #local PreRect = max (min (PreRect, 1), -1);
  #local Rect = asin (PreRect);
  #local RectDeg = degrees (Rect);
  #local RA = RectDeg - MA_Deg2Vector_RA_Offset;

  #if (abs(RA) < E) #local RA = 0; #end

  #while (RA < 0)
   #local RA = RA + 180;
  #end

  #if (S_X <= 0 & S_Z >=0)
   #local RA = 360 - RA;
  #end

  #if (S_X > 0  & S_Z >=0)
   #local RA = RA + 180;
  #end

  #if (S_X <= 0 & S_Z <=0)
   #local RA = 180 - RA;
  #end

  #if (S_X < 0 & S_Z =0)
   #local RA = 180 + RA;
  #end

  #local Result = <RA, Dec, Radius>;
 #end
 Result
#end


// Example round-trip test

#for (RA, 0, 360, 10)
 #for (Dec, -180, 180, 18)
  #local  V = <RA, Dec, 10>;
  #debug concat("RA = ", str(V.x,0,3), ", Dec = ", str(V.y,0,3), ", R = ",
str(V.z,0,3), "     ----->     ")

  #declare V1 = MA_Deg2Vector (V.x, V.y, V.z);
  #debug concat("X = ", str(V1.x,0,8), ", Y = ", str(V1.y,0,8), ", Z = ",
str(V1.z,0,3), "     ----->     ")

  #declare P1 = MA_Vector2Deg (V1); // P1 = <RA, Dec, R>
  #debug concat("RA = ", str(P1.x,0,3), ", Dec = ", str(P1.y,0,3), ", R = ",
str(P1.z,0,3),"\n")
 #end
 #debug "\n"
#end

#error "No objects in scene"

[Maetes] Re: "Clean" debugging [158 days 18 hours and 58 minutes ago]

Thu, 30 Oct 2025 22:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Try this alternate version:

Doesnt work.

It's untested AI-shit, right?

Please forget this macro.
I had hoped to get the invers-version of the Deg2Vector macro, but it has no
priority. Somewhen I will find the solution, but I will not invest another hour
in it.

ma

[Bald Eagle] Re: "Clean" debugging [158 days 20 hours and 43 minutes ago]

Thu, 30 Oct 2025 20:15:00 GMT

"Maetes" <nomail@nomail> wrote:

> Tanks, but unfortunately it crashes in the first line. After I fixed it, the
> result wasnt as expected. I tried more than an hour, without success.
> I will give it somewhen later anoter try.

Nein.

Try this alternate version:

returns a vector <RA, Declination, Radius> with angles in degrees and RA
normalized to [0,360).

#declare MA_Deg2Vector_RA_Offset = 0;
// Forward: (RA, Dec, Radius) -> <x, y, z>
#macro MA_Deg2Vector(S_RA, S_Dec, S_Radius)
#local S_Rect   = radians(S_RA + MA_Deg2Vector_RA_Offset);
#local S_DecRad = radians(S_Dec);
#local S_X = S_Radius * sin(S_DecRad) * cos(S_Rect);
#local S_Y = S_Radius * cos(S_DecRad);
#local S_Z = S_Radius * sin(S_DecRad) * sin(S_Rect);
#local V_Out = <S_X, -S_Y, S_Z>;
V_Out
#end
// Inverse: <x, y, z> -> <RA, Dec, Radius>
#macro MA_Vector2Deg(V_In)
// Undo the original Y inversion
#local S_X =  V_In.x;
#local S_Y = -V_In.y;
#local S_Z =  V_In.z;
#local S_Radius = sqrt(S_XS_X + S_YS_Y + S_Z*S_Z);
// Handle the degenerate zero-length vector
#if (S_Radius < 1e-12)
<0, 0, 0>
#else
// θ (the "rectangular" angle used in the forward mapping) from x,z
// NOTE: atan2(y, x) in POV-Ray; we want θ = atan2(z, x).
#local S_Theta = atan2(S_Z, S_X); // radians
// Recover sin(Dec) with its sign using both x & z and the θ we just found:
// x = r*sin(Dec)*cosθ, z = r*sin(Dec)*sinθ
// => x*cosθ + z*sinθ = r*sin(Dec)
#local S_SinDec = (S_X * cos(S_Theta) + S_Z * sin(S_Theta)) / S_Radius;

// Clamp for numeric safety
#if (S_SinDec >  1) #local S_SinDec =  1; #end
#if (S_SinDec < -1) #local S_SinDec = -1; #end

#local S_Dec = degrees(asin(S_SinDec));
#local S_RA  = degrees(S_Theta) - MA_Deg2Vector_RA_Offset;

// Normalize RA into [0, 360)
#while (S_RA < 0)
  #local S_RA = S_RA + 360;
#end
#while (S_RA >= 360)
  #local S_RA = S_RA - 360;
#end

<S_RA, S_Dec, S_Radius>

#end
#end



// Example round-trip test
//#declare V1 = MA_Deg2Vector(35, -20, 10);
//#declare P1 = MA_Vector2Deg(V1); // P1 = <RA, Dec, R>
//#debug concat("RA=",str(P1.x,0,3),", Dec=",str(P1.y,0,3),",
R=",str(P1.z,0,3),"\n")
// end of code

[Maetes] Re: "Clean" debugging [158 days 20 hours and 58 minutes ago]

Thu, 30 Oct 2025 20:00:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2025-10-23 14:16 (-4), Leroy wrote:
> > How about using debug.inc? It has some of the stuff you talked about.
>
> I looked at it years ago, and decided it didn't *quite* fit my needs.
> Taking another look at it just now, it seems that the macros are too
> general for my tastes.  I might use it if it fits exactly my needs, but
> then I'd have to remember check it for every project.  It just seems
> easier to write custom macros for each project.

What do you expect?

As written, I had already started with something like this. That you can tell
the debug "class" waypoints (executed macro X), pass variables, store everything
in a log file...

We could collect ideas.

I'm good at that. I'm lousy at textures and object design, but a good
programmer. If others would help me in exchange with textures and media without
me having a heart attack ...

...... that would be a extremly good deal for me.

Ma

PS:
I need a damn planetary atmosphere. A variable one, that really works with
serveral objects and sizes, and that I understand. Yes, I have found some
Threads here in the forum, but ... (heart attack)

[Maetes] Re: "Clean" debugging [158 days 21 hours and 8 minutes ago]

Thu, 30 Oct 2025 19:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Maetes" <nomail@nomail> wrote:
>
> > See:
> > https://www.maetes.com/en/povray-os/ma_helpers#ma-outputarraystring

> Hey - that's a really nice page with some useful stuff!

Tanks for that!

Since I have no idea if anyone uses my scripts at all, I have neglected new
releases for the last months. Halfway completing the code, documenting it
and presenting it on a page takes an enormous amount of time.

> I would love to see more exposure of people's work like yours, and some
> collaborative projects to develop equations, macros, and other tools to help
> keep things moving forward, so that we can make coding scenes easier and more
> efficient, identify and hopefully fix bugs, and create new features.

These could be my words. Maybe we will manage to exchange ideas better in the
future.

> As a small thanks, try the inverse macro following you own, and let me know if
> there are any problems.

Tanks, but unfortunately it crashes in the first line. After I fixed it, the
result wasnt as expected. I tried more than an hour, without success.
I will give it somewhen later anoter try.

The first and last output should be the same.
*** MA => Deg2Vector-Input: 100.000000,-50.000000,333.000000
*** MA => Deg2Vector-Result: 251.217,-214.048,44.296,0.000,0.000
*** MA => Vector2Deg-Result: 49.567539,7.644270,333.000000

Code:
--------
#local mRA = 100;
#local mDE = -50;
#local mRadius = 333;
MA_Terminal_AF("Deg2Vector-Input", array[3] { mRA, mDE, mRadius})
#local vResult = MA_Deg2Vector00 ( mRA, mDE, mRadius );
MA_Terminal_V("Deg2Vector-Result", vResult)
#local aResult = MA_Vector2Deg(vResult);
MA_Terminal_AF("Vector2Deg-Result", aResult)


Macro:
--------
#declare MA_Deg2Vector_RA_Offset = 0; // Define this globally if not already
#macro MA_Vector2Deg(mVector)
  #local mX =  mVector.x;
  #local mY = -mVector.y; // Invert Y to match original convention
  #local mZ =  mVector.z;

  #local Radius = sqrt (mX*mX + mY*mY + mZ*mZ);
  #local Declination = degrees (asin(mZ / Radius));
  #local RA = degrees (atan2(mX, mY)) - MA_Deg2Vector_RA_Offset;

  // Normalize RA to [0, 360)
  #while (RA < 0)
    #local RA = RA + 360;
  #end
  #while (RA >= 360)
    #local RA = RA - 360;
  #end

  array[3] { RA, Declination, Radius }
#end



ma

[Bald Eagle] Re: Future Editor options [160 days 23 hours and 18 minutes ago]

Tue, 28 Oct 2025 17:40:00 GMT

"ingo" <nomail@nomail> wrote:

> Not sure what you mean here, you can chop up any scene file in multiple include
> files and use a "render file" that unites them.

I can.  But I have a very military mindset when it comes to separability.
One is none.

If you CAN lose it, you WILL.

If a part can be "captive" rather than fully removable, do so.

I want a tar, zip, something file that is easily navigated for clean editing
without the clutter of constants and macros and functions, but is still all
right there in the SAME file.

I have many threads where I expand on all of this, but if I could svae an entire
directory structure with all of those includes, that would work for me too.

You yourself commented on the utility of an SQlite structure, which I applauded.

I have downloaded many scenes where I was missing the necessary variables or
include files.  Wrap them all up and keep them all together as a (still
immediately useable) package.  Even better if I can package that code into the
render image itself as metadata or a zip or pdf inside of a jpg/png.

You store ONE file - and either you have it or you don't.  You don't have to
worry about if you have missing pieces that you have to track down, or may be
gone forever.

- BW

[ingo] Re: Future Editor options [160 days 23 hours and 38 minutes ago]

Tue, 28 Oct 2025 17:20:00 GMT

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

> One of these is something that I expressed an interest in years ago - the
> ability to open different parts of a project in different tabs.

Not sure what you mean here, you can chop up any scene file in multiple include
files and use a "render file" that unites them.

ingo

[Bald Eagle] Re: Future Editor options [161 days and 48 minutes ago]

Tue, 28 Oct 2025 16:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> the IDE thing I had
> an interest in, in particular small "custom apps", like perhaps a spline editor,
> using POV-Ray to render "real-time" in a given (X) window id.

Without an extant development team capable of implementing such a thing, the
best that we have now is either the existing code - edit control points - render
cycle, or a third party software.
Even excel or open office would suffice for most spline types.
Ed Hynan wrote EPSpline.

Presumably Sergei, Ilya, or Leroy could code something up to display splines in
an "app" or online in Threejs.

One would imagine there are existing tools online to display simple splines.

Desmos actually is amazing.
https://www.desmos.com/calculator/norf40wc76

It would be easy enough to write some scenes in SDL to display whatever spline
you'd like.

What would be really cool is if we had something like a graphical GUI where you
could just add points with a mouse click and move them around with the mouse.
Some kind of software where the user could model the spline before raytracing
it...   We could call it a "modeler".  Then we could quickly get on with the
serious business of tracing more rays.  More. Rays.
Hey, I like the sound of that   - maybe we could name the modeler.....
.... nevermind.

> fwiw, being "old-fashioned" (or simply "old" :-)) I would not be keen "using
> special format comments", think that comments should be just that.

The evil spirits inhabiting the AI whispered to me that it would be as simple
as:

// @tab BEGIN Camera
camera { /* ... */ }
// @tab END

// @tab BEGIN Objects
object { /* ... */ }
// @tab END

As much as I am enamored of using tools for their proper, intended purpose, when
it comes right down to it, I'm not opposed to using a screwdriver as a prybar to
open a paint can, rather than purchasing or taking the time to hunt down a
single-purpose paint-can opener. (So long as the scredriver is not abused in the
process, or it's a cheap chai nesium throwaway)

If I can make efficient use of a dual purpose comment format, that makes
organizing my thoughts and debugging code quicker and more efficient, then I
would submit that we afford such a thing serious consideration.
I mean, just look at how you abuse code flow directives such as #if (1) ... #end
   instead of properly commenting with /* ... */   ;)

People older than you were fine with paper and pencil, a charred stick and
papyrus, or a mammoth bone in the sand.
Then those smarmy innovators came along with drums and smoke signals.
New-fangled fancy you choose to use a high-tech computer connected to a
world-wide high speed network.

:P

-bw

<thumps chest.  points.  ugh ugh.>

:D

[jr] Re: Future Editor options [161 days 1 hour and 48 minutes ago]

Tue, 28 Oct 2025 15:10:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
[editor]
> One of these is something that I expressed an interest in years ago - the
> ability to open different parts of a project in different tabs.
> ...
> Has anyone ever used any of the IDEs?
> Anyone interested in installing and exploring this idea?

personally have not even seen (or used) POV-Ray "official".  the IDE thing I had
an interest in, in particular small "custom apps", like perhaps a spline editor,
using POV-Ray to render "real-time" in a given (X) window id.

fwiw, being "old-fashioned" (or simply "old" :-)) I would not be keen "using
special format comments", think that comments should be just that.

regards, jr.

[Bald Eagle] Future Editor options [161 days 2 hours and 58 minutes ago]

Tue, 28 Oct 2025 14:00:00 GMT

In the absence of being able to engage in the code-debug-render cycle for other
ongoing projects, I've been opportunistically exploring other ideas.

One of these is something that I expressed an interest in years ago - the
ability to open different parts of a project in different tabs.

Apparently this would be possible with vs-code, and using special format
comments to demarcate various parts of the code to be opened in separate tabs
for editing.

An extension of this , for the AI enthusiasts, would be Cursor.

Has anyone ever used any of the IDEs?
Anyone interested in installing and exploring this idea?

- BW

[Cousin Ricky] Re: "Clean" debugging [161 days 18 hours and 46 minutes ago]

Mon, 27 Oct 2025 22:11:26 GMT

On 2025-10-23 14:16 (-4), Leroy wrote:
> How about using debug.inc? It has some of the stuff you talked about. I debug
> everything and I normally don't delete a debug but comment it out(never know
> when ya might need it again)
> Have Fun!

I looked at it years ago, and decided it didn't *quite* fit my needs.
Taking another look at it just now, it seems that the macros are too
general for my tastes.  I might use it if it fits exactly my needs, but
then I'd have to remember check it for every project.  It just seems
easier to write custom macros for each project.

[Cousin Ricky] Re: "Clean" debugging [161 days 18 hours and 51 minutes ago]

Mon, 27 Oct 2025 22:06:40 GMT

On 2025-10-23 10:04 (-4), Bald Eagle wrote:
> 
> It's simple, and I suppose obvious, but just thought I'd include it here in case
> anyone derives benefit from it.

I've done that on occasion.  I should perhaps do it more often.

[Bald Eagle] Re: "Clean" debugging [165 days 3 hours and 28 minutes ago]

Fri, 24 Oct 2025 13:30:00 GMT

"Maetes" <nomail@nomail> wrote:

> See:
> https://www.maetes.com/en/povray-os/ma_helpers#ma-outputarraystring
>
> ma

Hey - that's a really nice page with some useful stuff!
I especially like the look of that deprecated macro tool.

I will hopefully get a chance to look that over in depth at some point, and my
personal wish is that we get a lot of your ideas formally logged on the
newsgroup website or wiki in some way.

I would love to see more exposure of people's work like yours, and some
collaborative projects to develop equations, macros, and other tools to help
keep things moving forward, so that we can make coding scenes easier and more
efficient, identify and hopefully fix bugs, and create new features.

As a small thanks, try the inverse macro following you own, and let me know if
there are any problems.

#macro MA_Deg2Vector  (RightAscension, Declination, mRadius)
 #local mRect = radians(RightAscension + MA_Deg2Vector_RA_Offset);
 #local Declination = radians(Declination);
 //Here we have the critical lines
 #local mPosX = mRadius * sin(Declination) * cos (mRect);
 #local mPosY = mRadius * cos(Declination);
 #local mPosZ = mRadius * sin(Declination) * sin (mRect);
 #local mVector = <mPosX, mPosY * -1, mPosZ>;
 mVector
#end

Inverse:

#declare MA_Deg2Vector_RA_Offset = 0; // Define this globally if not already

#macro MA_Vector2Deg(Vector)
  #local x =  Vector.x;
  #local y = -Vector.y; // Invert Y to match original convention
  #local z =  Vector.z;

  #local Radius = sqrt (x*x + y*y + z*z);
  #local Declination = degrees (asin(z / Radius));
  #local RA = degrees (atan2(x, y)) - MA_Deg2Vector_RA_Offset;

  // Normalize RA to [0, 360)
  #while (RA < 0)
    #local RA = RA + 360;
  #end
  #while (RA >= 360)
    #local RA = RA - 360;
  #end

  array[3] { RA, Declination, Radius }
#end

- BW

[Maetes] Re: "Clean" debugging [165 days 4 hours and 3 minutes ago]

Fri, 24 Oct 2025 12:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I have had to include a lot of output to the debug stream to inspect values
> passed into macros, compare results of macros to tests done in other macros, and
> inspect the code flow so that I can see how the logic of various test results
> get directed.
>

I've also been on the verge of writing a pseudo debug class for Povray several
times

If you want to output arrays into a file, you can give my function a chance.

See:
https://www.maetes.com/en/povray-os/ma_helpers#ma-outputarraystring

ma

[Bald Eagle] Re: "Clean" debugging [165 days 21 hours and 18 minutes ago]

Thu, 23 Oct 2025 19:40:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> How about using debug.inc? It has some of the stuff you talked about.

1. Because I haven't used that file in over a decade, and forgot about it.

2. Why do that when I can reinvent the wheel?   :D

Thanks,

- BW

[Leroy] Re: "Clean" debugging [165 days 22 hours and 38 minutes ago]

Thu, 23 Oct 2025 18:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I have had to include a lot of output to the debug stream to inspect values
> passed into macros, compare results of macros to tests done in other macros, and
> inspect the code flow so that I can see how the logic of various test results
> get directed.
>
> Doing
> #if (Test)
>      #debug (something)
> #end
>
> clutters the code, is tedious, and if everything is spread out all across the
> code, it is a nightmare to turn on and off.
>
> So what I did was test for a Global_Debug identifier, and if defined, then I
> enable the #debug statements.
>
> I do that by creating a macro called Debug ()
>
> Then everything gets wrapped in Debug ( ), sans the #debug statement.
> Then it's just one line, can be kept in the code, is trivial to turn on and off,
> and all of the #if () #end stuff is in a single tiny macro.
>
> It's simple, and I suppose obvious, but just thought I'd include it here in case
> anyone derives benefit from it.
>
> - BE

How about using debug.inc? It has some of the stuff you talked about. I debug
everything and I normally don't delete a debug but comment it out(never know
when ya might need it again)
Have Fun!

[Bald Eagle] "Clean" debugging [166 days 2 hours and 48 minutes ago]

Thu, 23 Oct 2025 14:10:00 GMT

So, I have had to include a lot of output to the debug stream to inspect values
passed into macros, compare results of macros to tests done in other macros, and
inspect the code flow so that I can see how the logic of various test results
get directed.

Doing
#if (Test)
     #debug (something)
#end

clutters the code, is tedious, and if everything is spread out all across the
code, it is a nightmare to turn on and off.

So what I did was test for a Global_Debug identifier, and if defined, then I
enable the #debug statements.

I do that by creating a macro called Debug ()

Then everything gets wrapped in Debug ( ), sans the #debug statement.
Then it's just one line, can be kept in the code, is trivial to turn on and off,
and all of the #if () #end stuff is in a single tiny macro.

It's simple, and I suppose obvious, but just thought I'd include it here in case
anyone derives benefit from it.

- BE

[Bald Eagle] Re: POV-Ray source code development thread [168 days 3 hours and 23 minutes ago]

Tue, 21 Oct 2025 13:35:00 GMT

I probably spent about 5h last night working out various parts of the diagram.

There was still a bug lurking in my code, and tracked that down to a stray
identifier assignment.
After I fixed that, everything started working exactly as expected.

1. errors that are close to right, and that don't show up using standard
orientations are deceptive.  Move everything around.
2.This also highlights the dangers of global identifiers.
Or even identifiers that persist throughout the scope of your whole macro.

I got all my ray points and intersections properly plotted, and then worked out
how to calculate distances along the cylinder axis instead of the ray.  Then
this morning I worked out most of the circles I wanted to draw, and I've almost
got the last 2 essential points figured out.
Then I just need to orient all my labels to face the camera and parameterize the
point and line thicknesses.

> I found an equation for a general cylinder, however the radius wasn't correct when I
rendered it as an isosurface.
> I need to track down the source of that error and document it, because that
> would be useful.

I found another equation that was essentially the same, and a few others that
were total crap and slowed the rendering down to a standstill.
Got the good one working, and then...
Sometimes it would work, sometimes it wouldn't.

Radius 1 worked, not so much for 3 and 0.5

***Normalize the axis vector, Bill.***  Yes - now it all works.
Still need to just add in the translation so that it works for any orientation
and any position.

> As far as I am aware, we only have bounding boxes and spheres for isosurface
> shapes.   Odd that we don't have bounding cylinders.

Once I get this working nicely, I hope that we can get it applied to
isosurfaces.  Because rendering an oblique cylinder as an isosurface using an
axis-aligned bounding box leaves a LOT of empty space to test.
Using an oblique bounding cylinder with a small buffer would be spectacularly
efficient.
Note:  If one is rendering a complex isosurface with regions of empty space,
then it would probably be more efficient to define a number of unioned bounding
boxes of the same isosurface that only contain the shape and not the empty
space.  Just like the sor{} is a number of segments that are for all practical
purposes unioned{} under the hood.

> I also verified that we cannot transform that bounding box using something like
> the point_at or reorient_trans macros.

I believe that if we are able to add this functionality, it might speed up a lot
of renders.

> 2. The vector-based method that I'm using will allow cylinder end caps in any
> orientation.

I'll try to quickly code this up as a supplement to the right-angle-only
version.  May or may not do extensive testing, as I want to get moving along
this increasingly long daisy-chained to-do list.

Also would likely need to implement an insidedness test, which ought to be easy
to test with a ton of gridded and random points.

One thing I think I may do is implement this as a function call from the SDL
raytracing in the documentation to see if I can instantiate a bunch of cylinders
in various orientations and just render them all from within POV-Ray.  :D

> After I get that all sorted out, then I can hopefully start on properly bounding
> the Catmull-Rom spline to fix the blank-out bug.

I'm hoping that that will be a reasonably quick thing to do, since it's just
converting the spline to Bezier form, and pairing up a calculated radius with
the bounding polygon of each spline segment.

One thing I'm very curious about is whether or not we even need to DO bounding
tests for the sor.  If the vector method makes root-solving superfluous, then
I'll bet I can just work my way from base to top and do end-cap testing along
the entire sor {} to find intersections.  I'll think that out once I have the
basic implementation done.

I'm hoping to make some diagrams with macros to sequentially explain a lot of
the cross product and dot product calculations to show what they do and the
meaning of each part of the whole expression.

Then I think that rewriting the whole thing with better identifiers would be
essential, and then optimizing by working out each expression and canceling out
any repetitive factors. Maybe expand out all of the vectors, cross and dot
products and then cancel out all of the vector duplicate vector components.
Might be a job for Mathematica to make simplifying all of that faster and less
error-prone.

That might be it for now.

- BE

[Bald Eagle] Re: POV-Ray source code development thread [169 days 2 hours and 48 minutes ago]

Mon, 20 Oct 2025 14:10:00 GMT

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

> Will work on adding the end cap intersections and surface normals.

Update:

Surface normals got implemented first.
axis-aligned development cylinder worked fine, but when tilted, the normals were
wrong, prompting my vector cross-product question in another thread.

That was the result of using R instead of r, and so once everything gets to the
point of "working", I'll likely do more testing, and then refactor to use more
descriptive identifiers.



1. I found an equation for a general cylinder, however the radius wasn't correct
when I rendered it as an isosurface. (*)
I need to track down the source of that error and document it, because that
would be useful.
As far as I am aware, we only have bounding boxes and spheres for isosurface
shapes.   Odd that we don't have bounding cylinders.
I also verified that we cannot transform that bounding box using something like
the point_at or reorient_trans macros.

2. The vector-based method that I'm using will allow cylinder end caps in any
orientation.  This would likely allow a great saving in computation to make such
shapes, since we wouldn't have to do CSG and add a whole other layer of bounding
and intersection.
A proposed syntax for such a shape might be something like
cylinder {Start, End, Radius, optional StartNormal, optional EndNormal}

That way if no normals are supplied, then it's just the usual right-angle
cylinder.

There may better ways that make implementation easier.

- BE

After I get that all sorted out, then I can hopefully start on properly bounding
the Catmull-Rom spline to fix the blank-out bug.


(*)
searching again for such an equation (surprisingly hard to find) yields:
\((v_{y}(z-z_{0})-v_{z}(y-y_{0}))^{2}+(v_{z}(x-x_{0})-v_{x}(z-z_{0}))^{2}+(v_{x}(y-y_{0})-v_{y}(x-x_{0}))^{2}=(v_{x}^{2
}+v_{y}^{2}+v_{z}^{2})r^{2}\)

Which looks like it may have the corrective factor included as a coefficient of
r^2

also:

https://math.stackexchange.com/questions/1184038/what-is-the-equation-of-a-general-circle-in-3-d-space

[Bald Eagle] Re: POV-Ray source code development thread [171 days 22 hours and 48 minutes ago]

Fri, 17 Oct 2025 18:10:00 GMT

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

> I'll likely now be poring over the line/ray-cylinder intersection articles.
>
> (Since it is directly related to sor spline bounding, but also there seems to be
> issue with correctly rendering cylinders with an essentially unbounded endpoint)

Desmos 3d Graph
All vector math, no algebraic solver needed!

https://www.desmos.com/3d/c795aacwsb

(Just click on the orange surface icon on (at present) line 14 to toggle the
cylinder and see the vectors)

"A benefit of this geometric approach to the ray-cylinder intersection is that
it deals directly in object-space coordinates.  This avoids the overhead of
transforming either the rays and/or the bounded cylinder into a canonical form
for testing."

Will work on adding the end cap intersections and surface normals.

Enjoy,

- BE

[Bald Eagle] Re: POV-Ray source code development thread [173 days and 48 minutes ago]

Thu, 16 Oct 2025 16:10:00 GMT

Once again, I can't more highly recommend the Graphics Gems series, or how
important and helpful it would be for people interested in helping further
develop POV-Ray to begin implementing some of these algorithms.

Doing so in c++ would allow immediate test implementation, however implementing
them in SDL would allow others to play, learn, and become confident in
implementing algorithms of their own choosing.

http://cas.xav.free.fr/Graphics%20Gems%204%20-%20Paul%20S.%20Heckbert.pdf

I'll likely now be poring over the line/ray-cylinder intersection articles.

(Since it is directly related to sor spline bounding, but also there seems to be
issue with correctly rendering cylinders with an essentially unbounded endpoint)

- BE

(I was also excited to see a full polygonolization algorithm for implicit
surfaces just before the line-cylinder intersection articles!)

[Bald Eagle] POV-Ray source code development thread [183 days and 23 minutes ago]

Mon, 6 Oct 2025 16:35:00 GMT

Having picked my way, line by line, through a few thousand lines of our source
code for various reasons, I thought that it was time to look for a free
debugger.

CLion is free for student and open-source use.

https://www.jetbrains.com/clion/

- BE

[Thorsten] Re: Making POVRAY "interface less" and "language... [275 days and 29 minutes ago]

Sun, 6 Jul 2025 16:29:08 GMT

On 05.07.2025 14:45, The Entomologist wrote:
> GREAT QUESTIONS, DENIS!

You do realise that you are responding to a message that is more than 12 
years old?

> It is possible. But, yes, it would be difficult. I've tried a number of times,
> with different POV versions, the main problem being that you get a lot of errors
> when you try to compile them separately.

This is pure nonsense: You can compile each component separately. In 
fact, you can of course compile each source file separately. One could 
not put the components in libraries if this wasn't the case. So I 
suspect a user error on your part.

> The code is divided into two groups - front-end and back-end - which are
> supposed to represent what you describe as (1) user interface + parser in the
> "front" and the (2) renderer in the "back".

This is wrong. The parser is part of the backend.

> However, the documentation for
> programmers is a well kept a secret and I've found no description of the
> interface between the two. You'll have to find it yourself by trial and error.

No, you just have to be able to read source code and its (lengthy) 
comments. The software is open source, so there is no secret! - And as 
Ingo showed in another thread recently, even an AI can figure it out 
from the source code with surprising ease, see 
<web.6814726d2757792417bac71e8ffb8ce3@news.povray.org>

>   > > Would it be difficult to embed the function that reads the source code
>   > > (that represents the scene) and generates an image into a separate
>   > > process ?
> 
> It isn't clear what you mean by "a separate process". The renderer is
> multithreaded, if that's what you are after. As soon as one scene is being
> rendered, you may begin parsing the next.

Your answer is wrong. You can run multiple parsers in the same process 
as well. The parser is single-threaded, that is the only difference 
compared to the render threads.

> I honestly don't think you meant parallel runtime processing. But rather how to
> extract the rendering code from the rest of the code files. I've had the same
> issue a number of times. But I've never solved it. I was almost only interested
> in meshes and triangles, so I wrote a number of POV-files to generate those and
> then I traced the execution to see what back-end classes and functions were
> called and how. It doesn't solve every problem. But it gave me some idea of how
> a scene is built in memory before the rendering begins.

This is one of the easiest pieces of code to understand in POV-Ray...

> Then comes the issue of trying to figure out how and where the program gets the
> complete image after rendering. Sometimes it works. Somtimes it doesn't. And if
> you compile your own home made program to exe and run it, it never shows you the
> image.

What are you trying to say? Just because you cannot figure it out 
doesn't mean it does not work: Given you can see the image (or the file 
containing it) in the end, don't you think what you are saying implies 
more a lack of understanding on your part? The implication "Sometimes it 
works. Sometimes it doesn't." makes zero sense?!?!?

>   > I know the answer, but you are not ready for it.
> 
> Again, Le_Forgeron seems annoyd that someone wants to learn for free, what
> Le_Forgeron had to learn rhe hard way. Yet another missed opportunity to show
> off as one of the good guys. The above answer reads "I could explain it to you.
> But I'm far too lazy".

Well, does it occur to you that "open source" does not mean "open time"? 
If someone cannot understand the source code, they have to become 
sufficiently proficient in the programming language first. If they want 
to learn it, they have to put in the effort. Learning takes effort.

> To the rest of us, who always think we are better than the rest: Try to behave
> and do good. We are all here to help and get helped whenever possible. Some of
> us are beginners, others have been around for decades. Some, like Denis, wonder
> if the source code is worth even to begin working with.

*plonk*

[The Entomologist] Re: Making POVRAY "interface less" and "language... [276 days 4 hours and 8 minutes ago]

Sat, 5 Jul 2025 12:50:00 GMT

> > Would it be difficult to separate the renderer from the user interface ?
 > > ie:
 > > ### Question 1 :
 > > ### Question 2 :

GREAT QUESTIONS, DENIS!

It is possible. But, yes, it would be difficult. I've tried a number of times,
with different POV versions, the main problem being that you get a lot of errors
when you try to compile them separately.
The code is divided into two groups - front-end and back-end - which are
supposed to represent what you describe as (1) user interface + parser in the
"front" and the (2) renderer in the "back". However, the documentation for
programmers is a well kept a secret and I've found no description of the
interface between the two. You'll have to find it yourself by trial and error.

 > > Would it be difficult to embed the function that reads the source code
 > > (that represents the scene) and generates an image into a separate
 > > process ?

It isn't clear what you mean by "a separate process". The renderer is
multithreaded, if that's what you are after. As soon as one scene is being
rendered, you may begin parsing the next. But you can't begin rendering before
the parser has finished parsing.

I honestly don't think you meant parallell runtime processing. But rather how to
extract the rendering code from the rest of the code files. I've had the same
issue a number of times. But I've never solved it. I was almost only interested
in meshes and triangles, so I wrote a number of POV-files to generate those and
then I traced the execution to see what back-end classes and functions were
called and how. It doesn't solve every problem. But it gave me some idea of how
a scene is built in memory before the rendering begins.
Then comes the issue of trying to figure out how and where the program gets the
complete image after rendering. Sometimes it works. Somtimes it doesn't. And if
you compile your own home made program to exe and run it, it never shows you the
image.

 > > First: English is not my mother language. I do my best to be clear.
 > > ...
 > Nabla mu.

Responding with jibberish to someone, who has made it clear english might be a
hard language to read, seems unnessessarily rude.


 > Show us that you have spent more time on the subject than it would take some
of
 > us to answer in this thread.

This is another good example of how to not respond to a serious question. The
main reason why people ask questions in general is to save time when trying to
learn something new. If you want others to appreciate and use POV-Ray or any of
its forked projects, you should try to help. That's what these forums are for.


 > I know the answer, but you are not ready for it.

Again, Le_Forgeron seems annoyd that someone wants to learn for free, what
Le_Forgeron had to learn rhe hard way. Yet another missed opportunity to show
off as one of the good guys. The above answer reads "I could explain it to you.
But I'm far too lazy".


 > De gustibus... (et coloribus non est disputandum)
 > ...
 > Don't guess, look at the code and the compilation environment.

Again and again. #:(


 > Text in, image out... would you call latex a compiler ? (text in, document
 > out).
 > I would guess the right term would be a processor (as pre-processor).

It turns out, Le_Forgeron isn't that lazy after all. He puts a lot of effort
into trolling this thread. And it goes on. But I think I've made my point. My
apologies to Denis Beurive on behalf of the POV-Ray community for the abusive
responses he had to suffer here. I am amazed he didn't leave for good, but he
ignored the harsh tone and persisted in his inquiry.

To the rest of us, who always think we are better than the rest: Try to behave
and do good. We are all here to help and get helped whenever possible. Some of
us are beginners, others have been around for decades. Some, like Denis, wonder
if the source code is worth even to begin working with.

[Bald Eagle] Re: OpenGL's "Compute Shader" System [393 days 3 hours and 28 minutes ago]

Mon, 10 Mar 2025 13:30:00 GMT

"Rubber Telly Media" <rub### [at] gmailcom> wrote:
> Has anyone looked at the OpenGL "Compute Shader" System?
>
> It's being used for parallel processing of particle system simulations.

Having used Shadertoy, and converted many of the concepts of functional
programming to the generation of pigment {} patterns, I have a basic
understanding of how that works.

POV-Ray defines mathematical primitives and uses a ray-tracing approach.

The algorithms for object "detection", lighting, shadowing, etc. would likely
differ greatly, and so the entire WAY that these things would need to be
accomplished would have to be started from scratch to utilize the GPU in this
fashion.
If it could be done at all.
I'm not saying that it can't.  They are just fundamentally different ways of
doing things.

There are phrases and concepts in different (human) languages that simply can't
be adequately expressed in other languages.

Presumably this holds true for computer languages as well.

https://news.povray.org/povray.advanced-users/thread/%3Cweb.659879b9cca34dee1f9dae3025979125%40news.povray.org%3E/

https://www.shadertoy.com/

 -BE

[Rubber Telly Media] Re: OpenGL's "Compute Shader" System [393 days 3 hours and 48 minutes ago]

Mon, 10 Mar 2025 13:10:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 24/01/2025 14:03, jr wrote:
> > sorry, didn't mean to confuse, I must have put it poorly.  yes, I'd vote :-) for
> > a Tcl-like, transparent to the end-user, compilation of the SDL.  but if there
> > emerges a design based on a virtual machine rendering "backend", any language
> > will need to provide instructions for that, and we could see more than one of
> > the "traditional" scripting languages "extended" perhaps to emit "our"
> > byte-code.
>
> Thanks for correction. Really, LLVM - based parser could link POV-Ray
> with many other languages.
> --
> YB

Okay, apparently www.vulkan.org is another option for GPU programming, OpenGL is
supposed to be a bit heavy for Simple GPU programming.

But with Tens of Thousands of Floating-Point GPU Cores in your standard GPU, it
appears silly to be still using 4 to 16 CPU cores that suck at maths. CPUs are
well known for screwing up Floating-Point Maths (1.0+2.0=3.2 lol).

Oh and GLSL looks a lot like C Language. With a main that gets called for each
pixel by the cores, in a batch fashion...

Thank you, YouTube...I cannot find the original video; it appears to have been
taken down. But there are plenty on there still...

[Ray Gardener] Re: C++ version [397 days 9 hours and 48 minutes ago]

Thu, 6 Mar 2025 07:10:06 GMT

On 12/17/2021 10:31 AM, Alessio Sangalli wrote:
> Hello, what C++ version does the POV-Ray community want to target for 
> the future? I see POV_CPP11_SUPPORTED that as far as I were able to 
> understand is only used to define POVMS_NULLPTR, but older compilers are 
> supported too anyway.
> 
> Is there any reason to continue to support compilers older than C++11? 
> If we could just assume C++11 (or better, C++17) several sections of the 
> code could be rewritten to take advantage of new features of the 
> anguage. For example, I'd start with using constexpr instead of #define 
> in a lot of cases; kinda of a low hanging fruit, but type checking for 
> constants is in my opinion worth having in the 2020's.
> 

For what it's worth...

Visual Studio 2022 (or VS 17.x if you prefer) works fine, you only have 
to do this:

- Modify the BUILT_BY macro and comment out the related #error line in 
base/build.h like usual (if you haven't already).

- Comment out the inheritance of std::binary_function for the 
NameCompare struct in libraries/openexr/lmImf/mfAttribute.cpp
since std::binary_function is deprecated. Should be near line 65.

- In syspovconfig_msvc.h, add something like this to its list of MSVC 
toolchain definitions:

   #elif _MSC_VER >= 1940 && _MSC_VER < 1950
     #define POV_COMPILER_VER                  "msvc143"
     #define METADATA_COMPILER_STRING          "msvc 14.31"
     #define POV_CPP11_SUPPORTED               1


Ray Gardener

[Ray Gardener] TrueType::Copy method TODO comment likely should... [397 days 10 hours and 31 minutes ago]

Thu, 6 Mar 2025 06:26:31 GMT

Was browsing the source code of povray 3.7 stable and came across this 
in core/shape/truetype.cpp:

ObjectPtr TrueType::Copy()
{
     TrueType *New = new TrueType();
     Destroy_Transform(New->Trans);
     *New = *this;
     New->Trans = Copy_Transform(Trans);
     New->glyph = glyph; // TODO - How can this work correctly? [trf]
     return (New);
}

The issue posed by the TODO comment may be unnecessary,
because TrueType::glyph is pointing to the glyph data
in the loaded font so shared references are inherent and
responsibility of deletion rests with TrueTypeInfo::~TrueTypeInfo().

It does look sus at first glance because shapes like
heightfields and meshes increment reference counters
whenever copying pointers to heavy geometry, and their
destructors decrement the counter and then delete if
the counter reaches zero.

Since that's not the case here, I recommend changing
the TODO comment to something like: "This is okay; TrueTypeInfo has sole 
ownership of glyph and its dtor will dispose of it when font no longer 
in use."

A safer and more self-documenting way might be to use std::shared_ptr, 
but I understand that'd be a bit of work and the C++ transition is a 
work in progress.

Ray Gardener

[yesbird] Re: OpenGL's "Compute Shader" System [438 days 4 hours and 9 minutes ago]

Fri, 24 Jan 2025 12:48:32 GMT

On 24/01/2025 14:03, jr wrote:
> sorry, didn't mean to confuse, I must have put it poorly.  yes, I'd vote :-) for
> a Tcl-like, transparent to the end-user, compilation of the SDL.  but if there
> emerges a design based on a virtual machine rendering "backend", any language
> will need to provide instructions for that, and we could see more than one of
> the "traditional" scripting languages "extended" perhaps to emit "our"
> byte-code.

Thanks for correction. Really, LLVM - based parser could link POV-Ray
with many other languages.
--
YB

[jr] Re: OpenGL's "Compute Shader" System [438 days 5 hours and 53 minutes ago]

Fri, 24 Jan 2025 11:05:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> On 23/01/2025 10:59, Ilya Razmanov wrote:
> > Well, one may expect you to port POVRay to js and thus make questions
> > related ;-)
> ...
> While in SDL2 discussion jr votes for Tcl-like approach, I'd like to
> see JS/Typescript and JSON in next generation of SDL as they are simple,
> flexible and very popular.

sorry, didn't mean to confuse, I must have put it poorly.  yes, I'd vote :-) for
a Tcl-like, transparent to the end-user, compilation of the SDL.  but if there
emerges a design based on a virtual machine rendering "backend", any language
will need to provide instructions for that, and we could see more than one of
the "traditional" scripting languages "extended" perhaps to emit "our"
byte-code.

regards, jr.

[yesbird] Re: OpenGL's "Compute Shader" System [439 days 1 hour and 41 minutes ago]

Thu, 23 Jan 2025 15:16:54 GMT

On 23/01/2025 10:59, Ilya Razmanov wrote:
> Well, one may expect you to port POVRay to js and thus make questions 
> related ;-)
> 

)))
First step is already done here: https://povlab.yesbird.online.

While in SDL2 discussion jr votes for Tcl-like approach, I'd like to
see JS/Typescript and JSON in next generation of SDL as they are simple,
flexible and very popular.
--
YB

[Ilya Razmanov] Re: OpenGL's "Compute Shader" System [439 days 8 hours and 58 minutes ago]

Thu, 23 Jan 2025 07:59:25 GMT

On 22.01.2025 21:25, yesbird wrote:
> although this question has no relation to POV-Ray I will reply, that at
> present time I am working with Three.js and have a some shader-related
> projects here: https://yesbird.online
> 

Well, one may expect you to port POVRay to js and thus make questions 
related ;-)

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

[yesbird] Re: OpenGL's "Compute Shader" System [439 days 22 hours and 32 minutes ago]

Wed, 22 Jan 2025 18:25:52 GMT

On 21/01/2025 11:24, Rubber Telly Media wrote:
> Has anyone looked at the OpenGL "Compute Shader" System?
> 
> It's being used for parallel processing of particle system simulations.
> 
Hi,

although this question has no relation to POV-Ray I will reply, that at
present time I am working with Three.js and have a some shader-related
projects here: https://yesbird.online

As to particles, I suggest to look at this example: 
https://threejs.org/examples/?q=particles#webgpu_tsl_compute_attractors_particles

Happy shading !
--
YB

[Rubber Telly Media] OpenGL's "Compute Shader" System [441 days 8 hours and 33 minutes ago]

Tue, 21 Jan 2025 08:25:00 GMT

Has anyone looked at the OpenGL "Compute Shader" System?

It's being used for parallel processing of particle system simulations.

[Bald Eagle] Sturmian root solver [620 days 3 hours and 48 minutes ago]

Fri, 26 Jul 2024 13:10:00 GMT

Given that:

Sturm's theorem
The first complete root-isolation procedure results of Sturm's theorem (1829),
which expresses the number of real roots in an interval in terms of the number
of sign variations of the values of a sequence of polynomials, called Sturm's
sequence, at the ends of the interval. Sturm's sequence is the sequence of
remainders that occur in a variant of Euclidean algorithm applied to the
polynomial and its derivatives. When implemented on computers, it appeared that
root isolation with Sturm's theorem is less efficient than the other methods
that are described below.[3] Consequently, Sturm's theorem is rarely used for
effective computations, although it remains useful for theoretical purposes.

https://en.wikipedia.org/wiki/Real-root_isolation#Sturm's_theorem

And IIRC, we've had some issues concerning the current Sturmian root solver,

Maybe we ought to take a look into using the following:
SLV, ANewDsc:

The implementation of this algorithm appears to be more efficient than any other
implemented method for computing the real roots of a polynomial, even in the
case of polynomials having very close roots (the case which was previously the
most difficult for the bisection method).

https://arxiv.org/pdf/1308.4088

https://oaktrust.library.tamu.edu/bitstream/handle/1969.1/186132/JordanLamkin_EH-CSCE_honors_thesis.pdf?sequence=1&isAl
lowed=y

https://github.com/JDLamkin/Curve-Intersect


- BE

[Le Forgeron] Re: Help minimizing pre-processing graphic for A... [683 days 22 hours and 29 minutes ago]

Thu, 23 May 2024 18:29:02 GMT

Le 20/04/2024 Ã  23:28, Bald Eagle a Ã©critÂ :
> Hi folks,
> 
> Been busy and so, many things have stalled.
> 
> We've just had the concrete floors resurfaced - it looks like they've been
> ground down to fresh, clean concrete, and are likely to be sealed in the near
> future.
> 
> I had talked with the VP a while back about painting various lines on the floor,
> and I figured we could paint arrows in the direction of the nearest emergency
> exit.
> 
> So I ran A* on a simple map of the warehouse, and it does OK.
> It does take longer than I'd like to scan the image and generate the arrays of
> walkable vs non-walkable pixels, and then again to solve the "maze".
> 

> 
> I'd welcome any ideas, or even questions that help me avoid future unseen
> pitfalls.
> 
> - BW
> 

Can you consider as "Now safe" when reaching an external door, even if 
still far from the meeting point ?

If yes, I would set each external door a node of cost 0.
All nodes which are outside also get a cost of 0.
Other nodes start with unknown cost.

Ideally the grid of connections between nodes is your green/white picture.

Then just let diffuse the increasing cost by looping over each node:
- if cost is known, nothing to do
- if cost is still unknown, scan the neighbour nodes (taking the 
connection's map into account) for any known Cost, K=1+min(known cost of 
reachable neighbour).
- - if there is a know cost for at least one neighbour, set the cost of 
node to K
- - otherwise, ignore that node for this iteration.

Repeat as long as at least one node has been given a cost during iteration.

You might have different result according to the grid of nodes
- looking E,W,N,S only
- looking E,W,N,S but also NE,SE,NW,SW
- using hex-grid instead of square-grid (also 6 or 12 directions for 
neighbours)

Once you have finished the cost of every point, you can visualize it as 
a heightfield. (if your nodes are on a square grid) (I would recommend 
making "unknown cost" node at 0,
and adding a significant offset to the known cost, possibly with linear 
interpolation if the max cost get bigger than 65535-offset)


Why I did not use A* : because you are looking for the gradient of every 
point toward any exit, not routing a robot from A to B.
And the result is static.
So, it's the return of Dijkstra and diffusion of cost on a grid.

Notice that you can implement it with a "last updated node queue", but 
you would need to first replace the whole grid with a collection of 
nodes which hold coordinates of each allowed neighbour, but it is 
trading memory and precomputation of connections against simplicity of 
looping over a big array again and again.

[Kenneth] Re: Surprising change in speed of comparison ope... [703 days 23 hours and 18 minutes ago]

Fri, 3 May 2024 17:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> And it occurred to me while walking
> down a dark hallway, that when the algorithm is exploring potential directions
> from a pixel, it has EIGHT directions to choose from...

Although I haven't been following your path-finding scheme in detail-- real life
has interfered again-- I was wondering about those eight possible directions: As
you walk down the hallway, you already know that you have traversed the previous
pixel. So, it seems that at least that particular direction could be eliminated
from the search, while continuing along the path. Thus, SEVEN possible
directions instead of eight, for further searching. Not *much* of a speed
improvement, but every little bit helps. ;-)

That is, if I understand how your path-finding code is meant to operate...

[jr] Re: Surprising change in speed of comparison ope... [704 days 8 hours and 23 minutes ago]

Fri, 3 May 2024 08:35:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 02.05.2024 12:49, jr wrote:
> > ...
> > unsure I understand '!>' correctly, meaning "not greater" ?  if so, then that is
> > just another way of saying "less than", ie '<' (saving two keystrokes :-)).
>
> "Not greater" is "less or equal" actually ;-)

yes.  (I had one of my "shit-for-brains" days.  sorry)


> I'm just suggesting trying
> to do it some other way (different branch of "if" or something) and see
> what happens. Yes, I know that from math point of view it's the same,
> I'm suggesting to evaluate prog point of view ;-)

I've never looked at the povray source code (C++), but would be surprised if
adding a '!>' (and '!<' for "symmetry"?) operator were real "difficult".


regards, jr.

[Ilya Razmanov] Re: Surprising change in speed of comparison ope... [705 days 1 hour and 34 minutes ago]

Thu, 2 May 2024 15:23:47 GMT

On 02.05.2024 12:49, jr wrote:
> hi,
> 
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>> ...
>>> #if (walkability [a][b] != unwalkable)
>>> ...
>> Sorry for a stupid question, is there a way to use some !> instead of <=
>>
>> ?
> 
> 
> unsure I understand '!>' correctly, meaning "not greater" ?  if so, then that is
> just another way of saying "less than", ie '<' (saving two keystrokes :-)).

"Not greater" is "less or equal" actually ;-) I'm just suggesting trying 
to do it some other way (different branch of "if" or something) and see 
what happens. Yes, I know that from math point of view it's the same, 
I'm suggesting to evaluate prog point of view ;-)

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

[Bald Eagle] Re: Surprising change in speed of comparison ope... [705 days 6 hours and 8 minutes ago]

Thu, 2 May 2024 10:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm currently testing a hierarchical method of maze-solving to simulate 1-way
> doors, and I've made some very small changes which have resulted in a massive
> slowdown - probably 1/8 to 1/10 the original speed.  :O
>
> All I've done is replace 5 lines where comparisons using = now use a <= or a >.
> The first slowdown was noticed by changing a single line from
> #if (walkability [a][b] != unwalkable)
> to
> #if (walkability [a][b] <= Threshold)

One of the things about trying to do stuff like this with a renderer rather than
a language where you can draw directly on the screen in real time is that you're
always working blind.   It's like playing a long game of chess, but you make all
of the moves in your mind, and then just set up the chess board in the final
configuration.

I do believe the problem lies not in the operator, but in the consequences of
changing the behaviour of the pathfinding algorithm when using the inequalities
that I've specified.

Last night I ran a 100-person evacuation simulation, and although I was
expecting it to take a full 40 min, it only took 25.
I had implemented a timer to see how long it took to solve each path, and most
of the paths too around 900 ms, but some took nearly 3 minutes!

So I'm thinking that maybe somehow the logic has changed in such a way that it's
ignoring obstacles when it shouldn't be.  And it occurred to me while walking
down a dark hallway, that when the algorithm is exploring potential directions
from a pixel, it has EIGHT directions to choose from, which coincidentally was
the rate of slowdown (on average, for 50 solves).

I'll have to give it some more mental chess consideration as well as think about
ways to get better feedback about what the algorithm is doing during the course
of its search.

Maybe pick one of the LONG path-finding points and trace out the entire search
path.

- BW

[jr] Re: Surprising change in speed of comparison ope... [705 days 7 hours and 8 minutes ago]

Thu, 2 May 2024 09:50:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> ...
> > #if (walkability [a][b] != unwalkable)
> > ...
> Sorry for a stupid question, is there a way to use some !> instead of <=
>
> ?

unsure I understand '!>' correctly, meaning "not greater" ?  if so, then that is
just another way of saying "less than", ie '<' (saving two keystrokes :-)).

regards, jr.

[Ilya Razmanov] Re: Surprising change in speed of comparison ope... [705 days 10 hours and 7 minutes ago]

Thu, 2 May 2024 06:50:57 GMT

On 02.05.2024 4:39, Bald Eagle wrote:

> #if (walkability [a][b] != unwalkable)
> to
> #if (walkability [a][b] <= Threshold)

Sorry for a stupid question, is there a way to use some !> instead of <=

?

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

[Bald Eagle] Surprising change in speed of comparison operators [705 days 15 hours and 18 minutes ago]

Thu, 2 May 2024 01:40:00 GMT

I'm currently testing a hierarchical method of maze-solving to simulate 1-way
doors, and I've made some very small changes which have resulted in a massive
slowdown - probably 1/8 to 1/10 the original speed.  :O

All I've done is replace 5 lines where comparisons using = now use a <= or a >.
The first slowdown was noticed by changing a single line from
#if (walkability [a][b] != unwalkable)
to
#if (walkability [a][b] <= Threshold)

Also, there is one extra test block that got added:
#if (walkability [a][b] = exited)
    #declare Threshold = 5;
#end
{switches 1-way doors from a walkable path to an obstacle}

Has anyone experienced this sort of thing before?

Are there faster ways to do this sort of thing?
Using a ternary operator to assign a value rather than #if block?
Using a function rather than an inline equation?

I'm probably going to have to run my old function time-comparison scene file to
perform these types of methods 100,000 times and see if there's a massive
slowdown between = and >.

Really any suggestions are welcome.   This is now going WAY too slow.

[yesbird] Re: Help minimizing pre-processing graphic for A... [715 days 19 hours and 41 minutes ago]

Sun, 21 Apr 2024 21:17:07 GMT

On 21/04/2024 15:43, Bald Eagle wrote:
> I tried loading yesbird's povlab website to see if I could use that to speed up
> the parsing, but it's in a "forbidden country"   <eyeroll>

... or try VPN.

[yesbird] Re: Help minimizing pre-processing graphic for A... [715 days 20 hours and 24 minutes ago]

Sun, 21 Apr 2024 20:33:45 GMT

On 21/04/2024 15:43, Bald Eagle wrote:
> I tried loading yesbird's povlab website to see if I could use that to speed up
> the parsing, but it's in a "forbidden country"   <eyeroll>

Yes, guys, sad, but true. Last two years I'm living in "forbidden
country", trying to suppress this unpleasant fact. But "open source" is
always open and free, so if you have hardware resources, you can use my
code to make the same service in any "unforbidden" country:
https://github.com/syanenko/povlab.online
--
YB

[Bald Eagle] Re: Help minimizing pre-processing graphic for A... [716 days 4 hours and 13 minutes ago]

Sun, 21 Apr 2024 12:45:00 GMT

"ingo" <nomail@nomail> wrote:

> The print factory where I worked (solvent based rotogravure printing) was
> sectioned. Huge safety doors would close of sections in case of emergency.
> People would try to outrun the closing of these doors, the building is 250 m
> long with 5 sections. Not a situation you want.

Jeez.  Sounds like that scene from Moonraker.

> To get proper routes out we added more outside gathering points for
> people(counting). Maybe adding an extra gathering point (green dot?) on the
> other side of the building works?

I was just trying to make the solver take as long and convoluted path as I
could, and the algorithm that I have now only takes a start and target point as
input.
I think I can sequentially solve for different paths and store those in
different path number array, but at the present time, that's about it.

I was just trying to conceptually figure out how to code a 1-way door

After that, I figured some thing to try might be:
  solve a single designated path
  solve multiple single paths
  solve a progressive path with sequential destination points
  solve a single path then repeat using a given obstacle
  find the closest destination of many to a given starting point

But mostly I was just thinking that I might have to use different versions of
the map, or someone might want me to test this on another site, and I wanted to
minimize the amount of work I might need to do to start having the algorithm do
its thing.

I tried loading yesbird's povlab website to see if I could use that to speed up
the parsing, but it's in a "forbidden country"   <eyeroll>

- BE

[ingo] Re: Help minimizing pre-processing graphic for A... [716 days 11 hours and 3 minutes ago]

Sun, 21 Apr 2024 05:55:00 GMT

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

>
> So I ran A* on a simple map of the warehouse, and it does OK.
> It does take longer than I'd like to scan the image and generate the arrays of
> walkable vs non-walkable pixels, and then again to solve the "maze".
>

The print factory where I worked (solvent based rotogravure printing) was
sectioned. Huge safety doors would close of sections in case of emergency.
People would try to outrun the closing of these doors, the building is 250 m
long with 5 sections. Not a situation you want.

To get proper routes out we added more outside gathering points for
people(counting). Maybe adding an extra gathering point (green dot?) on the
other side of the building works?

ingo

[Bald Eagle] Help minimizing pre-processing graphic for A* pa... [716 days 19 hours and 28 minutes ago]

Sat, 20 Apr 2024 21:30:00 GMT

Hi folks,

Been busy and so, many things have stalled.

We've just had the concrete floors resurfaced - it looks like they've been
ground down to fresh, clean concrete, and are likely to be sealed in the near
future.

I had talked with the VP a while back about painting various lines on the floor,
and I figured we could paint arrows in the direction of the nearest emergency
exit.

So I ran A* on a simple map of the warehouse, and it does OK.
It does take longer than I'd like to scan the image and generate the arrays of
walkable vs non-walkable pixels, and then again to solve the "maze".

The real issue I'd like to solve is that A* didn't care that the shortest path
involved exiting the building and then coming back in.  That likely violates
policy, and plus the doors are exit-only (panic bar on the inside only).

At present, I'm just using image pixel color to define where empty space or a
door is, and everything else is solid object.  (the SDL currently draws over
anything it determines as solid - regardless of the color on the map -  with a
bright green, as a means evaluating the quality of the image colors & evaluation
logic)
Also, as you can see, the color logic is cumbersome and finicky - dark red
pallets get evaluated as "doors" (walkable space) and very dark grey doesn't
register as solid (because my logic sucks that bad)

#if (((PixelColor.red + PixelColor.green + PixelColor.blue)/3 < 0.9) &
(PixelColor.red < 0.85 & (PixelColor.green + PixelColor.blue)/2 > 0.05))

#declare walkability [X][Y] = unwalkable;

I'd like:
1. A clear manner of coding a door as being one-way.  Keep in mind that the door
in the graphic may be many pixels wide/deep, and there's no color
differentiation between inside and outside.

2. I'd like a general solution, but also one that minimizes the amount of
additional work to be done before running the pathfinding from the start point
to the destination (designated meeting place)

3. Any ideas on how to minimize the search time, even though they might cost
more initial work are welcome.  The idea is to run simulations when there may be
obstacles blocking the typical posted primary fire exit path.

I've been thinking of color coding, specifying a door <x, y> coupled with a
directional vector (I currently have 22 doors), using Crossing Numbers, Voronoi,
etc.

Also of interest is finding fire extinguishers, first aid kits, and AED
defibrillators.

With regard to fire extinguishers, I asked the question: what if I need one, but
someone has already taken it?  What direction do I go to get the next closest
one?  Or the third?

I'd welcome any ideas, or even questions that help me avoid future unseen
pitfalls.

- BW

[William F Pokorny] Re: Primitive BOX, how to wrap a texture? [876 days 12 hours and 54 minutes ago]

Mon, 13 Nov 2023 04:04:13 GMT

On 11/12/23 09:49, Mike Miller wrote:
> There is no 'box' mapping in POV.

Not to PILE ON :-)... There are at least five (six in yuqk) and probably 
more, but as Bill W. pointed out many require a special images for the 
inbuilt mapping.

Somewhere, I have a couple of user_defined cameras for creating the 
standard map forms for use with the inbuilt three box mapped methods. 
The second, more complicated camera tries to create images which should 
stand up better where users turn on interpolation.

Today, image interpolation at the edges of the standard box image 
folding cut out often introduces artifacts(a).

See:

https://wiki.povray.org/content/Reference:UV_Mapping

---
(a) You have used other render tooling, yes? If so, do you know how 
those tools handled interpolation of the images at the edges of the cut 
out regions for different parts of a uv mapped mesh?

Do they not use interpolation at all?

Are the images cut out regions created with extra buffer pixels to 
enable clean interpolation (smoothing) on the fly?

Or, do they just use really high resolution images for uv mapping so 
interpolation doesn't much matter and so they don't use it? If yes, I 
might guess by avoiding interpolation while rendering and on every 3D 
reach into the image map, they are gaining some performance this way?

This last I ask because I see POV-Ray folks often using interpolation 
with image maps used with uv mapping and I wonder if we should not be 
creating per-interpolated versions at higher resolutions for repeated 
rendering?

Bill P.

[GioSeregni] Re: Primitive BOX, how to wrap a texture? [876 days 19 hours and 53 minutes ago]

Sun, 12 Nov 2023 21:05:00 GMT

NOTE
Everything works in the metric system. The block cube is m.1x1x1
In this way if I choose X=1.65 the block will be 1.65 meter wide
The origin MUST be at the center to aid transformations and translations.
Textures are calibrated with the file name. In this case the pictures are large
m.1.20x1.20. In this way the size is transcribed in the pov file, and, since the
file is not "once", the texture is repeated by PovRay as much as necessary.
BR
G.

[GioSeregni] Re: Primitive BOX, how to wrap a texture? [876 days 20 hours and 18 minutes ago]

Sun, 12 Nov 2023 20:40:00 GMT

Well thanks to all!
Anyway here is how my parser works and writes on the parametric block that I
manage from AutoCAD in lisp.
Obviously the texture is unique, but as you can see it can also be easily edited
by hand.
I was hoping there was an automatic system, but this works anyway.
Just fix the proportions of the AutoCAD block as it is drawn...

global_settings {max_trace_level 3 assumed_gamma 1.5}
//#include "AI.inc"
camera {location<7.9629,2,0.7854>
//_________________________________________________
 right<1.3333,0,0>direction<0,0,1>look_at<7.1311,1.5000,4.7948>
}
union {
polygon{5,<-.5,0,-.5><-.5,0,.5><.5,0,.5><.5,0,-.5><-.5,0,-.5> scale<2,0,1>
 texture {pigment {image_map {png "120ROMANO"}  scale 1.20 rotate<90,0,0> }}}
polygon{5,<-.5,1,-.5><-.5,1,.5><.5,1,.5><.5,1,-.5><-.5,1,-.5> scale<2,0,1>
 texture {pigment {image_map {png "120ROMANO"}  scale 1.20 rotate<90,0,0> }}}
polygon{5,<-.5,0,.5><-.5,1,.5><.5,1,.5><.5,0,.5><-.5,0,.5> scale<2,0,1>
 texture {pigment {image_map {png "120ROMANO"}  scale 1.20 rotate<0,-0,0> }}}
polygon{5,<-.5,0,-.5><-.5,1,-.5><.5,1,-.5><.5,0,-.5><-.5,0,-.5> scale<2,0,1>
 texture {pigment {image_map {png "120porfido"}  scale 1.20 rotate<0,0,0> }}}
polygon{5,<-.5,0,-.5><-.5,1,-.5><-.5,1,.5><-.5,0,.5><-.5,0,-.5> scale<2,0,1>
 texture {pigment {image_map {png "120ROMANO"}  scale 1.20 rotate<0,-90,0> }}}
polygon{5,<.5,0,-.5><.5,1,-.5><.5,1,.5><.5,0,.5><.5,0,-.5> scale<2,0,1>
 texture {pigment {image_map {png "120ROMANO"}  scale 1.20 rotate<0,-90,0> }}}
finish {ambient(0.7*AmbientFact) diffuse .8 phong .8 phong_size 25}
rotate<0,320.0000,0> translate<7.0860,0.0000,4.7616>
}

light_source{<-10,10,-10> colour rgb 1
}
//sky_sphere {DAYSKY}

[Mike Miller] Re: Primitive BOX, how to wrap a texture? [876 days 21 hours and 33 minutes ago]

Sun, 12 Nov 2023 19:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > What! ...cubic pattern.
> > Does it work with image maps? I'm guessing so, since it references textures.
> > Must try out. I have an architectural project that could benefit.
> > Thanks, Mike.
>
> :D
> I know, right?   POV-Ray has SO much stuff that it's difficult to even keep
> track of it all, let alone document it, or implement it.
>
> Maybe check out this thread for starters:
>
>
https://news.povray.org/povray.binaries.images/thread/%3C5a6748f8%241%40news.povray.org%3E/
>
> - Bill

Thanks so much, ...good stuff.
I will investigate further.
Mike

[Bald Eagle] Re: Primitive BOX, how to wrap a texture? [876 days 22 hours and 3 minutes ago]

Sun, 12 Nov 2023 18:55:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> What! ...cubic pattern.
> Does it work with image maps? I'm guessing so, since it references textures.
> Must try out. I have an architectural project that could benefit.
> Thanks, Mike.

:D
I know, right?   POV-Ray has SO much stuff that it's difficult to even keep
track of it all, let alone document it, or implement it.

Maybe check out this thread for starters:

https://news.povray.org/povray.binaries.images/thread/%3C5a6748f8%241%40news.povray.org%3E/

- Bill

[Mike Miller] Re: Primitive BOX, how to wrap a texture? [876 days 22 hours and 48 minutes ago]

Sun, 12 Nov 2023 18:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Also, I forgot to mention the cubic pattern, which might make things
> substantially easier.
>
> https://wiki.povray.org/content/Reference:Cubic_Pattern

What! ...cubic pattern.
Does it work with image maps? I'm guessing so, since it references textures.
Must try out. I have an architectural project that could benefit.
Thanks, Mike.

[Bald Eagle] Re: Primitive BOX, how to wrap a texture? [876 days 23 hours and 3 minutes ago]

Sun, 12 Nov 2023 17:55:00 GMT

Also, I forgot to mention the cubic pattern, which might make things
substantially easier.

https://wiki.povray.org/content/Reference:Cubic_Pattern

[Mike Miller] Re: Primitive BOX, how to wrap a texture? [876 days 23 hours and 43 minutes ago]

Sun, 12 Nov 2023 17:15:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "GioSeregni" <gms### [at] hotmailcom> wrote:
> > > First of all, I apologize for the naivety of the question.
> > > I am not able to get the surfaces of the BOX with the actual texture.
> > >
> > > Example:
> > >
> > > box{<0.5000,1.0000,0.2500>,<-3,-1.0000,-0.2500>
> > >  texture {pigment {image_map
> > >  {png "130PINK" map_type 1
> > >  interpolate 2
> > > }
> > >  scale 1.30
> > > }}
> > >  rotate<0,360.0000,0> translate<46.7000,-0.0900,14.0700>
> > > }
> > >
> > > Well, Map 0 fails on some faces, Map 1 and map 2 deform the texture.
> > > How can I wrap a texture correctly?
> > > I studied the UV Mapping, but I practically understood nothing.
> > > How should I correct my example to get the same texture uniformly on all faces?
> > > A huge thank you if anyone helps me.
> > >
> > > BR
> > > Giovanni
> >
> > Check out:
> > https://wiki.povray.org/content/Reference:UV_Mapping
> >
> > The key lines that you want to pay attention to are:
> >
> > texture {
> >     uv_mapping
> >
> > The uv_mapping statement needs to preceed everything else in the texture
> > definition for it to work.
> >
> > Also, depending on how you want that box mapped, then yes, there is indeed a box
> > mapping, but you need to set up the texture specifically to do that, which might
> > not be a simple task.
> >
> > - Bill
>
> Thanks!
>
> in fact I tried but I didn't understand how to implement UV mapping. We would
> need at least one example on a cube, on which the texture is wrapped uniformly.
> Then everything else, scaling, translating, rotating, re-proportioning on the
> axes, is simple.
> G

This is one simple way I've mapped boxes or flat surfaces at different angles.
Create the surface slightly larger than what's needed. Difference the surface
with plane or planes that match the angles needed. The planes would carry the
material and transferred the image_map or material to the differenced shape.
Each rotated plane can have its own material, so a 6-sided cube could have 6
materials.
Hope this help,
Mike.

[Bald Eagle] Re: Primitive BOX, how to wrap a texture? [877 days and 28 minutes ago]

Sun, 12 Nov 2023 16:30:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:

> Thanks!
>
> in fact I tried but I didn't understand how to implement UV mapping.

No problem.  I've been at this for 10 years, and just recently got pretty
confused about the specifics.
https://news.povray.org/povray.general/thread/%3Cweb.641d4cf6eebe912c9b4924336e066e29%40news.povray.org%3E/

We would
> need at least one example on a cube, on which the texture is wrapped uniformly.

Right.  So if you look at the diagram on the wiki, it will show you what needs
to be where, and the exact coordinates for all of the faces.  So you could
image-map some squares and render that with an orthographic camera to give you
an image-map suitable for further uv-mapping,

or

you could write some more complex code to just grab the filenames and make the
uv-mapping texture in memory and do everything in a 1-step render.  And I'd
really need to go look up and study the exact details of doing it that way.

> Then everything else, scaling, translating, rotating, re-proportioning on the
> axes, is simple.

Yes.

- BW

[GioSeregni] Re: Primitive BOX, how to wrap a texture? [877 days 1 hour and 3 minutes ago]

Sun, 12 Nov 2023 15:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > First of all, I apologize for the naivety of the question.
> > I am not able to get the surfaces of the BOX with the actual texture.
> >
> > Example:
> >
> > box{<0.5000,1.0000,0.2500>,<-3,-1.0000,-0.2500>
> >  texture {pigment {image_map
> >  {png "130PINK" map_type 1
> >  interpolate 2
> > }
> >  scale 1.30
> > }}
> >  rotate<0,360.0000,0> translate<46.7000,-0.0900,14.0700>
> > }
> >
> > Well, Map 0 fails on some faces, Map 1 and map 2 deform the texture.
> > How can I wrap a texture correctly?
> > I studied the UV Mapping, but I practically understood nothing.
> > How should I correct my example to get the same texture uniformly on all faces?
> > A huge thank you if anyone helps me.
> >
> > BR
> > Giovanni
>
> Check out:
> https://wiki.povray.org/content/Reference:UV_Mapping
>
> The key lines that you want to pay attention to are:
>
> texture {
>     uv_mapping
>
> The uv_mapping statement needs to preceed everything else in the texture
> definition for it to work.
>
> Also, depending on how you want that box mapped, then yes, there is indeed a box
> mapping, but you need to set up the texture specifically to do that, which might
> not be a simple task.
>
> - Bill

Thanks!

in fact I tried but I didn't understand how to implement UV mapping. We would
need at least one example on a cube, on which the texture is wrapped uniformly.
Then everything else, scaling, translating, rotating, re-proportioning on the
axes, is simple.
G

[Bald Eagle] Re: Primitive BOX, how to wrap a texture? [877 days 1 hour and 33 minutes ago]

Sun, 12 Nov 2023 15:25:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:
> First of all, I apologize for the naivety of the question.
> I am not able to get the surfaces of the BOX with the actual texture.
>
> Example:
>
> box{<0.5000,1.0000,0.2500>,<-3,-1.0000,-0.2500>
>  texture {pigment {image_map
>  {png "130PINK" map_type 1
>  interpolate 2
> }
>  scale 1.30
> }}
>  rotate<0,360.0000,0> translate<46.7000,-0.0900,14.0700>
> }
>
> Well, Map 0 fails on some faces, Map 1 and map 2 deform the texture.
> How can I wrap a texture correctly?
> I studied the UV Mapping, but I practically understood nothing.
> How should I correct my example to get the same texture uniformly on all faces?
> A huge thank you if anyone helps me.
>
> BR
> Giovanni

Check out:
https://wiki.povray.org/content/Reference:UV_Mapping

The key lines that you want to pay attention to are:

texture {
    uv_mapping

The uv_mapping statement needs to preceed everything else in the texture
definition for it to work.

Also, depending on how you want that box mapped, then yes, there is indeed a box
mapping, but you need to set up the texture specifically to do that, which might
not be a simple task.

- Bill

[GioSeregni] Re: Primitive BOX, how to wrap a texture? [877 days 1 hour and 38 minutes ago]

Sun, 12 Nov 2023 15:20:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > First of all, I apologize for the naivety of the question.
> > I am not able to get the surfaces of the BOX with the actual texture.
> >
.....
> > How should I correct my example to get the same texture uniformly on all faces?
> > A huge thank you if anyone helps me.
> >
> > BR
> > Giovanni
>
> There is no 'box' mapping in POV. You could hand code the box out of clipped
> planes, mapping each side by rotating map 'type 0' to face each side. There's
> probably a macro that someone has written to do just that.
>
> I wrote a macro that 'box maps' the Round_Box macro. It can simulate a square
> edged box if you set the edge radius fillet very low.
> Miller
>
> //  make mapped box
> //  diced Round_Box() into a 6 sided uv mapped Round Box
> //  m.miller  05.21.23
>
> #include "shapes.inc"
> #include "shapes2.inc"
>
>
> #macro make_mapped_box (w,h,d,f,mat,z_dir)
> #declare _form = object{ Round_Box(<-w/2,0,0>,<w/2,h,d>, f , 1) }
> union {
>     // X  right
>     difference {
>          object { _form }
>          plane { <1,0,0>, 0 translate <w/2-f/2,0,0> }
>          plane { <1,0,0>, 0 rotate <0,-45,0> translate <w/2,0,0> }
>          plane { <1,0,0>, 0 rotate <0,45,0> translate <w/2,0,d> }
>          plane { <0,-1,0>, 0 rotate <0,0,45> translate <w/2,h,0> }
>          plane { <0, 1,0>, 0 rotate <0,0,-45> translate <w/2,0,0> }
>          material {mat rotate <0,-90,0> translate <0,0,0> }
>          #if (z_dir)
>             material {mat rotate <0,-90,0> rotate <90,0,0> translate <0,0,0> }
>          #end
>          rotate <0,0,0>
>          translate <0,0,0>
>    }
>
>
>     // X  left
>     difference {
>          object { _form }
>          plane { <1,0,0>, 0 translate <w/2-f/2,0,0> }
>          plane { <1,0,0>, 0 rotate <0,-45,0> translate <w/2,0,0> }
>          plane { <1,0,0>, 0 rotate <0,45,0> translate <w/2,0,d> }
>          plane { <0,-1,0>, 0 rotate <0,0,45> translate <w/2,h,0> }
>          plane { <0, 1,0>, 0 rotate <0,0,-45> translate <w/2,0,0> }
>          material {mat rotate <0,-90,0> translate <0,0,0> }
>          #if (z_dir)
>             material {mat rotate <0,-90,0> rotate <90,0,0> translate <0,0,0> }
>          #end
>          rotate <0,180,0>
>          translate <0,0,d>
>     }
>
>
>     // Y  top/bottom
>     difference {
>          object { _form }
>          plane {<0,-1,0> 0 rotate <0,0,0> translate <0,f/2,0>}
>          plane {<0,-1,0> 0 rotate <-45,0,0> translate <0,0,0>}
>          plane {<0,-1,0> 0 rotate <45,0,0> translate <0,0,d>}
>          plane {<0,-1,0> 0 rotate <0,0,-45> translate <w/2,0,0>}
>          plane {<0,-1,0> 0 rotate <0,0,45> translate <-w/2,0,0>}
>          material {mat rotate <-90,180,0> translate <-w/2,0,0> }
>          rotate <0,0,0>
>          translate <0,0,0>
>     }
>
>     // Y  top/bottom
>     difference {
>          object { _form }
>          plane {<0,-1,0> 0 rotate <0,0,0> translate <0,f/2,0>}
>          plane {<0,-1,0> 0 rotate <-45,0,0> translate <0,0,0>}
>          plane {<0,-1,0> 0 rotate <45,0,0> translate <0,0,d>}
>          plane {<0,-1,0> 0 rotate <0,0,-45> translate <w/2,0,0>}
>          plane {<0,-1,0> 0 rotate <0,0,45> translate <-w/2,0,0>}
>          material {mat rotate <-90,180,0> translate <-w/2,0,0> }
>          rotate <0,0,180>
>          translate <0,h,0>
>     }
>
>     // Y  front
>     difference {
>          object { _form }
>
>          plane { <0,0,-1>, 0 translate <0,0,f/2> }
>          plane {<-1,0,0>,0 rotate <0,-45,0> translate <w/2,0,0>     }
>          plane {<1,0,0>,0  rotate <0,45,0>  translate <-w/2,0,0>   }
>          plane {<0,-1,0>,0   rotate <45,0,0>  translate <0,h,0> }
>          plane {<0,1,0>,0   rotate  <-45,0,0>  translate <0,0,0> }
>          material {mat rotate <0,0,0> translate <-w/2,0,0> }
>          rotate <0,0,0>
>          translate <0,0,0>
>     }
>
>     // Y  back
>     difference {
>          object { _form }
>          plane { <0,0,-1>, 0 translate <0,0,f/2> }
>          plane {<-1,0,0>,0 rotate <0,-45,0> translate <w/2,0,0>     }
>          plane {<1,0,0>,0  rotate <0,45,0>  translate <-w/2,0,0>   }
>          plane {<0,-1,0>,0   rotate <45,0,0>  translate <0,h,0> }
>          plane {<0,1,0>,0   rotate  <-45,0,0>  translate <0,0,0> }
>          material {mat rotate <0,0,0> translate <-w/2,0,0> }
>          rotate <0,180,0>
>          translate <0,0,d>
>     }
>
> }
> #end
>
> ---------------------------------------
> Usage example:
>
>
> #declare _mat    =   M_wood;
> #declare _z_dir  =   1;
> #declare _fillet =   .2;
> #declare _width  =   5;
> #declare _height =   5;
> #declare _depth  =   10;
>
> object { make_mapped_box(_width, _height, _depth, _fillet, _mat, _z_dir)
> translate <0,0,-_depth/2> rotate <0,30,0> translate <-10,0,0>}


Thank you very much, now I am sure that it is not possible and therefore my
technique makes sense, very similar to yours, for which I thank you.
My parser for PovRay from AutoCAD, written in lisp, in fact, works like this
(polygons instead of planes):

(if (= "DKBCASE"  block)
 (progn
 (IniPovObj)

(write-line (strcat "union
{polygon{5,<-.5,0,.5><.5,0,.5><.5,0,-.5><-.5,0,-.5><-.5,0,.5>") fil) ;1 BOTTOM
(write-line (strcat " scale<"(rtos scX)","(rtos scZ)","(rtos scY)">") fil)
(setq need 0) (filler)
(if (= need 1)(write-line "}" fil))(if (= need 2)(write-line "}}" fil))(if (=
need 3)(write-line "}}}" fil)) ;endif
(write-line rotateXstring fil)(write-line closestring fil)


(write-line (strcat "
polygon{5,<-.5,1,-.5><-.5,1,.5><.5,1,.5><.5,1,-.5><-.5,1,-.5>") fil) ;2 TOP
(write-line (strcat " scale<"(rtos scX)","(rtos scZ)","(rtos scY)">") fil)
(setq need 0) (filler) ............
.............

NOTE the Sub filler essewntially chooses the image...
MANY THANKS!
G.

[Mike Miller] Re: Primitive BOX, how to wrap a texture? [877 days 2 hours and 3 minutes ago]

Sun, 12 Nov 2023 14:55:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:
> First of all, I apologize for the naivety of the question.
> I am not able to get the surfaces of the BOX with the actual texture.
>
> Example:
>
> box{<0.5000,1.0000,0.2500>,<-3,-1.0000,-0.2500>
>  texture {pigment {image_map
>  {png "130PINK" map_type 1
>  interpolate 2
> }
>  scale 1.30
> }}
>  rotate<0,360.0000,0> translate<46.7000,-0.0900,14.0700>
> }
>
> Well, Map 0 fails on some faces, Map 1 and map 2 deform the texture.
> How can I wrap a texture correctly?
> I studied the UV Mapping, but I practically understood nothing.
> How should I correct my example to get the same texture uniformly on all faces?
> A huge thank you if anyone helps me.
>
> BR
> Giovanni

There is no 'box' mapping in POV. You could hand code the box out of clipped
planes, mapping each side by rotating map 'type 0' to face each side. There's
probably a macro that someone has written to do just that.

I wrote a macro that 'box maps' the Round_Box macro. It can simulate a square
edged box if you set the edge radius fillet very low.
Miller

//  make mapped box
//  diced Round_Box() into a 6 sided uv mapped Round Box
//  m.miller  05.21.23

#include "shapes.inc"
#include "shapes2.inc"


#macro make_mapped_box (w,h,d,f,mat,z_dir)
#declare _form = object{ Round_Box(<-w/2,0,0>,<w/2,h,d>, f , 1) }
union {
    // X  right
    difference {
         object { _form }
         plane { <1,0,0>, 0 translate <w/2-f/2,0,0> }
         plane { <1,0,0>, 0 rotate <0,-45,0> translate <w/2,0,0> }
         plane { <1,0,0>, 0 rotate <0,45,0> translate <w/2,0,d> }
         plane { <0,-1,0>, 0 rotate <0,0,45> translate <w/2,h,0> }
         plane { <0, 1,0>, 0 rotate <0,0,-45> translate <w/2,0,0> }
         material {mat rotate <0,-90,0> translate <0,0,0> }
         #if (z_dir)
            material {mat rotate <0,-90,0> rotate <90,0,0> translate <0,0,0> }
         #end
         rotate <0,0,0>
         translate <0,0,0>
   }


    // X  left
    difference {
         object { _form }
         plane { <1,0,0>, 0 translate <w/2-f/2,0,0> }
         plane { <1,0,0>, 0 rotate <0,-45,0> translate <w/2,0,0> }
         plane { <1,0,0>, 0 rotate <0,45,0> translate <w/2,0,d> }
         plane { <0,-1,0>, 0 rotate <0,0,45> translate <w/2,h,0> }
         plane { <0, 1,0>, 0 rotate <0,0,-45> translate <w/2,0,0> }
         material {mat rotate <0,-90,0> translate <0,0,0> }
         #if (z_dir)
            material {mat rotate <0,-90,0> rotate <90,0,0> translate <0,0,0> }
         #end
         rotate <0,180,0>
         translate <0,0,d>
    }


    // Y  top/bottom
    difference {
         object { _form }
         plane {<0,-1,0> 0 rotate <0,0,0> translate <0,f/2,0>}
         plane {<0,-1,0> 0 rotate <-45,0,0> translate <0,0,0>}
         plane {<0,-1,0> 0 rotate <45,0,0> translate <0,0,d>}
         plane {<0,-1,0> 0 rotate <0,0,-45> translate <w/2,0,0>}
         plane {<0,-1,0> 0 rotate <0,0,45> translate <-w/2,0,0>}
         material {mat rotate <-90,180,0> translate <-w/2,0,0> }
         rotate <0,0,0>
         translate <0,0,0>
    }

    // Y  top/bottom
    difference {
         object { _form }
         plane {<0,-1,0> 0 rotate <0,0,0> translate <0,f/2,0>}
         plane {<0,-1,0> 0 rotate <-45,0,0> translate <0,0,0>}
         plane {<0,-1,0> 0 rotate <45,0,0> translate <0,0,d>}
         plane {<0,-1,0> 0 rotate <0,0,-45> translate <w/2,0,0>}
         plane {<0,-1,0> 0 rotate <0,0,45> translate <-w/2,0,0>}
         material {mat rotate <-90,180,0> translate <-w/2,0,0> }
         rotate <0,0,180>
         translate <0,h,0>
    }

    // Y  front
    difference {
         object { _form }

         plane { <0,0,-1>, 0 translate <0,0,f/2> }
         plane {<-1,0,0>,0 rotate <0,-45,0> translate <w/2,0,0>     }
         plane {<1,0,0>,0  rotate <0,45,0>  translate <-w/2,0,0>   }
         plane {<0,-1,0>,0   rotate <45,0,0>  translate <0,h,0> }
         plane {<0,1,0>,0   rotate  <-45,0,0>  translate <0,0,0> }
         material {mat rotate <0,0,0> translate <-w/2,0,0> }
         rotate <0,0,0>
         translate <0,0,0>
    }

    // Y  back
    difference {
         object { _form }
         plane { <0,0,-1>, 0 translate <0,0,f/2> }
         plane {<-1,0,0>,0 rotate <0,-45,0> translate <w/2,0,0>     }
         plane {<1,0,0>,0  rotate <0,45,0>  translate <-w/2,0,0>   }
         plane {<0,-1,0>,0   rotate <45,0,0>  translate <0,h,0> }
         plane {<0,1,0>,0   rotate  <-45,0,0>  translate <0,0,0> }
         material {mat rotate <0,0,0> translate <-w/2,0,0> }
         rotate <0,180,0>
         translate <0,0,d>
    }

}
#end

---------------------------------------
Usage example:


#declare _mat    =   M_wood;
#declare _z_dir  =   1;
#declare _fillet =   .2;
#declare _width  =   5;
#declare _height =   5;
#declare _depth  =   10;

object { make_mapped_box(_width, _height, _depth, _fillet, _mat, _z_dir)
translate <0,0,-_depth/2> rotate <0,30,0> translate <-10,0,0>}

[GioSeregni] Primitive BOX, how to wrap a texture? [877 days 3 hours and 28 minutes ago]

Sun, 12 Nov 2023 13:30:00 GMT

First of all, I apologize for the naivety of the question.
I am not able to get the surfaces of the BOX with the actual texture.

Example:

box{<0.5000,1.0000,0.2500>,<-3,-1.0000,-0.2500>
 texture {pigment {image_map
 {png "130PINK" map_type 1
 interpolate 2
}
 scale 1.30
}}
 rotate<0,360.0000,0> translate<46.7000,-0.0900,14.0700>
}

Well, Map 0 fails on some faces, Map 1 and map 2 deform the texture.
How can I wrap a texture correctly?
I studied the UV Mapping, but I practically understood nothing.
How should I correct my example to get the same texture uniformly on all faces?
A huge thank you if anyone helps me.

BR
Giovanni

[aysays] Problem with macros and translate function :/ [958 days 4 hours and 53 minutes ago]

Wed, 23 Aug 2023 12:05:00 GMT

Hello I'm new to Pov-Ray and am trying to write a broccoli fractal code however
I'm having problems with the translate function. If I understood it correctly,
translate only accepts numerical values. I tried writing a macro but that didn't
work either. How am I supposed to write a recursive function that utilizes
translate? :/ Here is my code:

#include "colors.inc"

global_settings {
    ambient_light rgb <1, 1, 1>
    assumed_gamma 1.0
}

camera {
    location <0, 0, -25>
    look_at <0, 0, 0>
}

light_source {
    <-100, -100, -100>
    color rgb <1, 1, 1>
}

#declare phi = (1 + sqrt(5))/2;
#declare ang = 360 * (1 - 1/phi);




#macro trans()
    translate< sqrt(i)* cos(i * ang),
           sqrt(i) * sin(i * ang),
           10-sqrt(pow(sqrt(i)* cos(i * ang),2) + pow(sqrt(i) * sin(i *
ang),2))>
#end

#macro frac(n)
    #if(n > 0)
        cone {
            <0, 10, 0>, 10
            <0, 0, 0>, 0
            texture {
                pigment { Green }
                finish { ambient 0.2 }
            }


        #declare i = 1;
        #while (i <= 100)
            //#declare theta = i * ang;
            //#declare r = sqrt(i);
            //#declare a = r * cos(theta);
            //#declare b = r * sin(theta);


            trans()



            scale 0.15
       }
            frac(n - 1)

            #declare i = i + 1;
        #end
    #end
#end

frac(3);



Thanks in advance :)

[And] Re: How to design the structure of a graphic com... [997 days 2 hours and 18 minutes ago]

Sat, 15 Jul 2023 14:40:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
>
> I'd like to see this done. :)

Oh, oh... I see.

> Can't help you with java...sorry. I use VB for all my POV macros and tools -
> mostly to convert Blender objects including 2D spines to POV syntax. Easy to
> parse and lots of free 2D and 3D canvas tools.  and compiles to .exe.
> Mike

Ok.
I just thought that maybe I can found someone who are proficient at
(General/Object Oriented) designing of GUI program.

[Mike Miller] Re: How to design the structure of a graphic com... [997 days 12 hours and 43 minutes ago]

Sat, 15 Jul 2023 04:15:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> I wrote a java program last year:
>
http://news.povray.org/povray.binaries.utilities/thread/%3Cweb.62b9d31097c0f8e9cf20f667aa81652d%40news.povray.org%3E/

>
> I will rewrite it (because I have wrote some corresponding POV-macro for the
> functions, I can reserve them, and other consequent), especially the Curve
> Editor which can use mouse drag node to edit curves.
>
> Maybe I will release that component to GitHub under open-source license in the
> future.
>
> But I need some suggestion about write such a graphic component. Because I found
> my
> structure of the program is not ideal. It is hard to complete all features what
> I want. I have paused effort on it, But I remember I spend much time developing
> it last 1-2 years.
>
> I use Java language to implement them, but generally it is not the emphasis.

I'd like to see this done. :)
Can't help you with java...sorry. I use VB for all my POV macros and tools -
mostly to convert Blender objects including 2D spines to POV syntax. Easy to
parse and lots of free 2D and 3D canvas tools.  and compiles to .exe.
Mike

[And] How to design the structure of a graphic compone... [998 days 10 hours and 18 minutes ago]

Fri, 14 Jul 2023 06:40:00 GMT

I wrote a java program last year:
http://news.povray.org/povray.binaries.utilities/thread/%3Cweb.62b9d31097c0f8e9cf20f667aa81652d%40news.povray.org%3E/

I will rewrite it (because I have wrote some corresponding POV-macro for the
functions, I can reserve them, and other consequent), especially the Curve
Editor which can use mouse drag node to edit curves.

Maybe I will release that component to GitHub under open-source license in the
future.

But I need some suggestion about write such a graphic component. Because I found
my
structure of the program is not ideal. It is hard to complete all features what
I want. I have paused effort on it, But I remember I spend much time developing
it last 1-2 years.

I use Java language to implement them, but generally it is not the emphasis.

[jr] strSplit macro. [998 days 17 hours and 38 minutes ago]

Thu, 13 Jul 2023 23:20:00 GMT

hi,

included below is a small macro which is part of a currently stalled "pet"
project.  it reads a string containing a list of items, separated by some
character, splits it, and returns an array of the string items.

eg.
#declare list = "one two three";
#declare words = strSplit(list,chr(32));

leaves 'one' in 'words[0]' etc.  an empty list element produces an empty array
element.  hope you will find it useful.


regards, jr.

--------<snip>--------
#macro strSplit(s_,sep_)
  #local n_ = strlen(s_);
  #if (!n_)
    #error "strSplit: string must not be empty."
  #elseif (1 != strlen(sep_))
    #error "strSplit: separator must be a single character."
  #end
  #local a_ = array;
  #local f_ = false;
  #local i_ = 1;
  #local k_ = 0;
  #while (n_ >= i_)
    #if (!strcmp(sep_,substr(s_,i_,1)))
      #if ((i_ - 1) = k_) #local t_ = "";
      #else #local t_ = substr(s_,(k_ + 1),(i_ - k_ - 1));
      #end
      #if (n_ = i_) #local f_ = true; #end
      #local a_[dimension_size(a_,1)] = t_;
      #local k_ = i_;
      #undef t_
    #elseif (n_ = i_)
      #local a_[dimension_size(a_,1)] = substr(s_,(k_ + 1),(i_ - k_));
    #end
    #local i_ = i_ + 1;
  #end
  #if (f_) #local a_[dimension_size(a_,1)] = ""; #end
  a_
#end
--------<snip>--------

[Bald Eagle] Re: Raw_Normal [1018 days 1 hour and 13 minutes ago]

Sat, 24 Jun 2023 15:45:00 GMT

"225012156" <225### [at] csueducn> wrote:


It looks like you're doing everything properly to me.
There may be some issues with the original vertex values, rounding, etc that
make the numbers you are getting slightly different when doing it POV-Ray vs
another computer language.

I know that under the hood certain numbers are represented as doubles rather
than longs, etc.

But you're doing it the right way.  It's certainly the way I learned how to do
it.

https://www.scratchapixel.com/lessons/geometry/bezier-curve-rendering-utah-teapot/bezier-patch-normal.html

- BE

[jr] Re: Raw_Normal [1018 days 11 hours and 3 minutes ago]

Sat, 24 Jun 2023 05:55:00 GMT

hi,

"225012156" <225### [at] csueducn> wrote:
> What exactly is the definition of Raw_Normal? ... tried to
> construct a little triangular element ...
> # Calculate normal vector (cross product)
> normal = np.cross(edge1, edge2)
>
> # Normalized normal vector
> normal_normalized = normal / np.linalg.norm(normal)
>
> return normal_normalized
> The output is [-0.41867126 0.80698158-0.41652743]
> This is really confusing to me

hoping that my lack of maths won't betray me :-) but aren't you comparing
"apples and oranges" ?  the face normal of a triangle is not the same as a
'vcross' product.  (see first link for 'vcross' definition, second link is a C
program source where face normals get calculated (as an option).  hth)

<https://wiki.povray.org/content/Reference:Vector_Expressions#Functions>
<https://drive.google.com/file/d/10WT-D3MP4qYxnP1BYu5f_ZN_xmOo1P5W/view?usp=sharing>

regards, jr.

[225012156] Raw_Normal [1018 days 14 hours and 8 minutes ago]

Sat, 24 Jun 2023 02:50:00 GMT

What exactly is the definition of Raw_Normal? I always thought it was a normal
vector on the surface where the light intersects with Object, but I tried to
construct a little triangular element
#declare fugai_48 = mesh2 {
vertex_vectors {
3
<-4.50633802, 3.69271012, -10.9775885>,
<-4.65835461, 3.42382252, -11.3457332>,
<-4.93662437, 3.47962036, -10.95792829>,
}
face_indices {
1
The < 0 >,
}
}
Its Raw_Normal is [-0.41867095 0.80698168-0.41652757]
But I wrote a function in python that computes the normal vector of a surface
def calculate_normalized_normal(v1, v2, v3):
# Compute two side vectors
edge1 = v2 - v1
edge2 = v3 - v1

# Calculate normal vector (cross product)
normal = np.cross(edge1, edge2)

# Normalized normal vector
normal_normalized = normal / np.linalg.norm(normal)

return normal_normalized
The output is [-0.41867126 0.80698158-0.41652743]
This is really confusing to me

[Bald Eagle] Re: IPoint [1032 days 4 hours and 48 minutes ago]

Sat, 10 Jun 2023 12:10:00 GMT

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

> yes, translate, but POVRay say :
> -10.591118 + 3.000000 = -7.591118
>
> and "225012156" wrote that z is equal to -7.656250
> so a gap of 0.065132.
>
> another subtlety ?

There are two vertices with z = -10.591118
and one with z = -10.833504

#declare base_02 = mesh2 {
vertex_vectors {
3
<2.952163, 3.632734, -10.591118>,
<1.556791, 3.632964, -10.593109>,
<2.93827, 3.516272, -10.833504>,
}

So it's not completely vertical, which means the intersection point will be
farther back than -10.591118.  The z coordinate of the centroid of the
translated triangle lies at  -7.67195467, but maybe it's intersecting at one of
the other triangle centers.

- BE

[kurtz le pirate] Re: IPoint [1032 days 7 hours and 37 minutes ago]

Sat, 10 Jun 2023 09:21:05 GMT

On 07/06/2023 11:11, ingo wrote:
> "225012156" <225### [at] csueducn> wrote:
> 
>> I mean, obviously the z coordinate of the mesh2 Object is around -10, but how
>> does it intersect at -7.656250?
> 
> maybe because of translate <0, 0, 3>?

yes, translate, but POVRay say :
-10.591118 + 3.000000 = -7.591118

and "225012156" wrote that z is equal to -7.656250
so a gap of 0.065132.

another subtlety ?






-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: IPoint [1035 days 6 hours and 53 minutes ago]

Wed, 7 Jun 2023 10:05:00 GMT

hi,
"225012156" <225### [at] csueducn> wrote:
> ...
> Thank you.I also found this mistake after sending this message. Sorry to bother
> you with such a small problem

no problem.  (I see such "slip ups" to mean that a (short) break, to have a
coffee or doing something else, is due.  ;-))

regards ,jr.

[ingo] Re: IPoint [1035 days 7 hours and 43 minutes ago]

Wed, 7 Jun 2023 09:15:00 GMT

"225012156" <225### [at] csueducn> wrote:

> I mean, obviously the z coordinate of the mesh2 Object is around -10, but how
> does it intersect at -7.656250?

maybe because of translate <0, 0, 3>?

ingo

[225012156] Re: IPoint [1035 days 8 hours and 3 minutes ago]

Wed, 7 Jun 2023 08:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "225012156" <225### [at] csueducn> wrote:
> > ...
> > #declare base_02 = mesh2 {
> > vertex_vectors {
> > 3
> > <2.952163, 3.632734, -10.591118>,
> > <1.556791, 3.632964, -10.593109>,
> > <2.93827, 3.516272, -10.833504>,
> > }
> > face_indices {
> > 1
> > <0,1, 2>,
> > }
> > }
> > union {
> > object {base_02
> > texture {
> > pigment { color rgb<1.0, 1.0, 1.0> }
> > finish {reflection {0.5} ambient 0 diffuse 0.015 specular 0.7 roughness 0.00085}
> > }
> > }
> > translate <0, 0, 3> //
> > rotate <0, 0, 0> //
> > }
> > Why is its IPoint
> > 1.976229 3.602266-7.656250
> > 2.419499 3.601889-7.656250
> > 2.862769 3.601512-7.656250
> > I mean, obviously the z coordinate of the mesh2 Object is around -10, but how
> > does it intersect at -7.656250?
>
> hope I interpret correctly, but is -10 + (translate 3) not 7 ?  :-)
>
>
> regards, jr.

Thank you.I also found this mistake after sending this message. Sorry to bother
you with such a small problem

[jr] Re: IPoint [1035 days 8 hours and 18 minutes ago]

Wed, 7 Jun 2023 08:40:00 GMT

hi,

"225012156" <225### [at] csueducn> wrote:
> ...
> #declare base_02 = mesh2 {
> vertex_vectors {
> 3
> <2.952163, 3.632734, -10.591118>,
> <1.556791, 3.632964, -10.593109>,
> <2.93827, 3.516272, -10.833504>,
> }
> face_indices {
> 1
> <0,1, 2>,
> }
> }
> union {
> object {base_02
> texture {
> pigment { color rgb<1.0, 1.0, 1.0> }
> finish {reflection {0.5} ambient 0 diffuse 0.015 specular 0.7 roughness 0.00085}
> }
> }
> translate <0, 0, 3> //
> rotate <0, 0, 0> //
> }
> Why is its IPoint
> 1.976229 3.602266-7.656250
> 2.419499 3.601889-7.656250
> 2.862769 3.601512-7.656250
> I mean, obviously the z coordinate of the mesh2 Object is around -10, but how
> does it intersect at -7.656250?

hope I interpret correctly, but is -10 + (translate 3) not 7 ?  :-)


regards, jr.

[225012156] IPoint [1035 days 8 hours and 58 minutes ago]

Wed, 7 Jun 2023 08:00:00 GMT

I tried to output the IPoint of each ray, but I found something was not right
I built the following small mesh2Object
camera {
orthographic
location <20.0, 54.949548, 0.0>
look_at <0.0, 0.0, 0.0>
right 100*x
up 100*y
}

light_source {
<20.0, 54.949548, 0.0>
color rgb<1, 1, 1>
parallel
point_at <0.0, 0.0, 0.0>
}


#declare base_02 = mesh2 {
vertex_vectors {
3
<2.952163, 3.632734, -10.591118>,
<1.556791, 3.632964, -10.593109>,
<2.93827, 3.516272, -10.833504>,
}
face_indices {
1
<0,1, 2>,
}
}
union {
object {base_02
texture {
pigment { color rgb<1.0, 1.0, 1.0> }
finish {reflection {0.5} ambient 0 diffuse 0.015 specular 0.7 roughness 0.00085}
}
}
translate <0, 0, 3> //
rotate <0, 0, 0> //
}
Why is its IPoint
1.976229 3.602266-7.656250
2.419499 3.601889-7.656250
2.862769 3.601512-7.656250
I mean, obviously the z coordinate of the mesh2 Object is around -10, but how
does it intersect at -7.656250?

[225012156] Ray_Intersection->Object [1036 days 2 hours and 23 minutes ago]

Tue, 6 Jun 2023 14:35:00 GMT

I found a property Ray_Intersection->Object, so how do I output the Object where
each ray intersects? For example, I have a very large mesh2 Object,
#declare base_02 = mesh2 {
vertex_vectors {
n
< 2.31603771, 3.60210208, 7.65598937 >,
< 1.80618269, 3.72980798, 7.39113238 >,
< 1.8064666, 3.47488795, 7.92162825 >,
....
But each ray will only intersect one of these smaller mesh2,
#declare base_02 = mesh2 {
vertex_vectors {
3
< 2.31603771, 3.60210208, 7.65598937 >,
< 1.80618269, 3.72980798, 7.39113238 >,
< 1.8064666, 3.47488795, 7.92162825 >,
How do I output it in pov format

[Lars Rohwedder] U+02CA vs. U+0301 [1191 days 4 hours and 35 minutes ago]

Mon, 2 Jan 2023 12:22:31 GMT

> So I think issue is on POV Ray. I'm using (it's anoying work) a combination of
> "i" without dot and a separate diacritic: \u0131 and \u02ca.

\u02ca ist the wrong character. It is a "spacing" letter, not a 
"combining diacrticial mark" (which are intended to be combined with a 
letter).

See:

https://en.wikipedia.org/wiki/Spacing_Modifier_Letters

vs.

https://en.wikipedia.org/wiki/Combining_Diacritical_Marks
â€”Â where the 
"combining acute accent" is at U+0301.

Lars R.

[Lars Rohwedder] Re: bad display of utf8 code u00ed letter i-accu... [1191 days 4 hours and 48 minutes ago]

Mon, 2 Jan 2023 12:09:30 GMT

Am 31.12.22 um 16:46 schrieb tx2378:
> For times new roman (could be on another fonts too) the latin letter Ã
(i-accute
> utf8 escape sequence "\u00ed" is bad displayed.
> 
> See this text sentence:
> 
> text{ttf "times" "El aj\u00ed estaba picante" 0 0 scale 100}
> 
> How can I resolve this issue?
> 

Have you set the correct charset in global settings?

See: https://www.povray.org/documentation/3.7.0/r3_4.html#r3_4_1_6


Lars R.

P.S.: https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_7_2 
does not mention how characters beyond the BMP are handled at all.

[Bald Eagle] Re: bad display of utf8 code u00ed letter i-accu... [1191 days 19 hours and 58 minutes ago]

Sun, 1 Jan 2023 21:00:00 GMT

"tx2378" <tx2### [at] naranjaplatanocom> wrote:

> reason, work with Times New Roman. Anyway issue is on POV Ray treatment of some
> font families.
> Try this on HTML:
> <style>
> @font-face {font-family:pot; src: url('file:///c:/windows/fonts/times.TTF')}
> div {font-family:pot;font-size:300px}
> </style>
> <div>
>
>
> And Then this, on POV Ray:
> global_settings{charset utf8}
> camera{location -1000*z look_at 0}
> background{color rgb 1}
> text{ttf "C:\windows\fonts\times.ttf" "Ah\u00ed" 0 0
>      scale 700
>      translate<-580,-200>}
>
> On both I'm using times new roman from Windows 10. HTML works properly but on
> POV Ray you'll see that diacritic is ahead from "i".
>
> So I think issue is on POV Ray. I'm using (it's anoying work) a combination of
> "i" without dot and a separate diacritic: \u0131 and \u02ca.

I mean, I'm certainly not saying you're wrong - but I would guess that with
POV-Ray's simplistic handling of all font-related stuff, it's probably going to
be the most true-to-file interpretation.

I seem to recall some issue with Windows falling back onto backup fonts for
missing glyphs in certain character sets.

Try taking a look at the font in the Windows Character Map, or better - a 3rd
party font file viewer like FontForge.  Also maybe WordPad or Notepad.

Options:

clipka had mentioned being able to copy-paste a unicode character into the
POV-Ray text editor, and the parser would correctly identify and interpret that
without any other special treatment.

Cousin Ricky and I have manually converted the character definitions into Bezier
spline objects.

You could dissect the body of the i and the diacritical using masks / CSG and
define a custom made character as an object {}

Use just that character from another font that sufficiently resembles Times.

Use a browser or word processor and screenshot the correctly displayed text and
use that as an image_map billboard with a transparent background.

POV-Ray was really designed as a graphical raytracer, not as something that
handles a lot of text like a word processor.

[tx2378] Re: bad display of utf8 code u00ed letter i-accu... [1192 days and 48 minutes ago]

Sun, 1 Jan 2023 16:10:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "tx2378" <tx2### [at] naranjaplatanocom> wrote:
> >
> > utf8 escape sequence "\u00ed" is bad displayed.
> >
> > See this text sentence:
> >
> > text{ttf "times" "El aj\u00ed estaba picante" 0 0 scale 100}
> >
> > How can I resolve this issue?
>
> First of all, if you aren't already using global_settings { charset utf8 }, you
> need to do so.
>
> But it seems that *none* of the lowercase i glyphs with diacriticals display
> properly, with most of the fonts I've tried.  The newer generation Microsoft
> fonts do work, though; try "cambria".
>
> N.B. to jr:  The fonts bundled with POV-Ray are all pure nonsense outside the
> 7-bit ASCII range.  They are not a good test of anything.

Hi;

I´ve try Garamond Regular.ttf instead, and it works ok. But I need, for any
reason, work with Times New Roman. Anyway issue is on POV Ray treatment of some
font families.
Try this on HTML:
<style>
@font-face {font-family:pot; src: url('file:///c:/windows/fonts/times.TTF')}
div {font-family:pot;font-size:300px}
</style>
<div>
Ahí

And Then this, on POV Ray:
global_settings{charset utf8}
camera{location -1000*z look_at 0}
background{color rgb 1}
text{ttf "C:\windows\fonts\times.ttf" "Ah\u00ed" 0 0
     scale 700
     translate<-580,-200>}

On both I'm using times new roman from Windows 10. HTML works properly but on
POV Ray you'll see that diacritic is ahead from "i".

So I think issue is on POV Ray. I'm using (it's anoying work) a combination of
"i" without dot and a separate diacritic: \u0131 and \u02ca.

[Cousin Ricky] Re: bad display of utf8 code u00ed letter i-accu... [1192 days 19 hours and 28 minutes ago]

Sat, 31 Dec 2022 21:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> > ...
> > N.B. to jr:  The fonts bundled with POV-Ray are all pure nonsense outside the
> > 7-bit ASCII range.  They are not a good test of anything.
>
> agree that the distribution fonts aren't "a good test".  fwiw, two have some
> usable/useful glyphs above 127, see attached.

They are usable, sure, but they do not correspond to standard character sets.

[Bald Eagle] Re: bad display of utf8 code u00ed letter i-accu... [1192 days 21 hours and 53 minutes ago]

Sat, 31 Dec 2022 19:05:00 GMT

> agree that the distribution fonts aren't "a good test".  fwiw, two have some
> usable/useful glyphs above 127, see attached.
>
>
> regards, jr.

clipka said that they're "borked".

jr's table macro would be a great addition to the scripts that render all the
illustrations for the distribution - in the insert menu, etc.

Going through all of the .fon, .ttf, files and checking to see if there's a
corresponding jpg, png, bmp, and then rendering the ones that don't would be a
nice way to allow periodic updating of the font/include directory as new fonts
are added. (date, time, font name, full path)  It's def a good tool to help
unravel the complex morass which are fonts and how the different versions of
POV-Ray interpret them with/without the utf8 keyword.
(That would also be a good addition: side-by-side comparison of the same font
with & without the utf8 keyword)

It's also a great way to show someone the contents of a typeface file before
they decide to hunt it down and download/install it on their system.

The chili is definitely spicy.

[jr] Re: bad display of utf8 code u00ed letter i-accu... [1192 days 22 hours and 33 minutes ago]

Sat, 31 Dec 2022 18:25:00 GMT

hi,

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> ...
> N.B. to jr:  The fonts bundled with POV-Ray are all pure nonsense outside the
> 7-bit ASCII range.  They are not a good test of anything.

agree that the distribution fonts aren't "a good test".  fwiw, two have some
usable/useful glyphs above 127, see attached.

regards, jr.

[Bald Eagle] Re: bad display of utf8 code u00ed letter i-accu... [1192 days 23 hours and 8 minutes ago]

Sat, 31 Dec 2022 17:50:00 GMT

Give "Abhaya Libre" a try, WITH charset utf8 in the global settings.

https://www.fontsquirrel.com/fonts/download/abhaya-libre


https://www.fontsquirrel.com/fonts/list/language/spanish

[Cousin Ricky] Re: bad display of utf8 code u00ed letter i-accu... [1192 days 23 hours and 13 minutes ago]

Sat, 31 Dec 2022 17:45:00 GMT

"tx2378" <tx2### [at] naranjaplatanocom> wrote:
>
> utf8 escape sequence "\u00ed" is bad displayed.
>
> See this text sentence:
>
> text{ttf "times" "El aj\u00ed estaba picante" 0 0 scale 100}
>
> How can I resolve this issue?

First of all, if you aren't already using global_settings { charset utf8 }, you
need to do so.

But it seems that *none* of the lowercase i glyphs with diacriticals display
properly, with most of the fonts I've tried.  The newer generation Microsoft
fonts do work, though; try "cambria".

N.B. to jr:  The fonts bundled with POV-Ray are all pure nonsense outside the
7-bit ASCII range.  They are not a good test of anything.

[Bald Eagle] Re: bad display of utf8 code u00ed letter i-accu... [1193 days and 8 minutes ago]

Sat, 31 Dec 2022 16:50:00 GMT

"tx2378" <tx2### [at] naranjaplatanocom> wrote:
>
> utf8 escape sequence "\u00ed" is bad displayed.
>
> See this text sentence:
>
> text{ttf "times" "El aj\u00ed estaba picante" 0 0 scale 100}
>
> How can I resolve this issue?

So, I get a capital I with a left-tilted ' and a larger size than the rest of
the font, when I use Times Regular.

I'm going to guess that you need to switch to a different font with the proper
utf glyphs in the character set.

You may or may not need to add charset utf8 to your global settings

It's all very confusing.

https://news.povray.org/povray.advanced-users/thread/%3Cweb.60e50c29d0fecd301f9dae3025979125%40news.povray.org%3E/

[jr] Re: bad display of utf8 code u00ed letter i-accu... [1193 days and 18 minutes ago]

Sat, 31 Dec 2022 16:40:00 GMT

hi,

"tx2378" <tx2### [at] naranjaplatanocom> wrote:
>
> utf8 escape sequence "\u00ed" is bad displayed.
>
> See this text sentence:
>
> text{ttf "times" "El aj\u00ed estaba picante" 0 0 scale 100}
>
> How can I resolve this issue?

you'll need a different font.  when I use 'cyrvetic.ttf' I get a letter/glyph
(though, I suspect, not the one you're after).

regards, jr.

[tx2378] bad display of utf8 code u00ed letter i-accute i... [1193 days 1 hour and 8 minutes ago]

Sat, 31 Dec 2022 15:50:00 GMT

For times new roman (could be on another fonts too) the latin letter í (i-accute
utf8 escape sequence "\u00ed" is bad displayed.

See this text sentence:

text{ttf "times" "El aj\u00ed estaba picante" 0 0 scale 100}

How can I resolve this issue?

[Bruno Cabasson] Re: PROOF : Pov Ray Object Oriented Features : a... [1476 days 7 hours and 3 minutes ago]

Wed, 23 Mar 2022 09:54:39 GMT

Le 06/03/2022 Ã  19:46, kennebel a Ã©critÂ :
> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> ....
>> Currently, I am unit-testing my core PROOF code. Then, I will try to write some
>> illustrative examples of how to use classes to improve and extend POV obects as
>> well as their behaviour. For example, I can imagine classes that helps you
>> visualize Bounding Boxes (if useful), place your objects in your scenes (use of
>> trace(), which cannot be done outside the parser without rewriting intersection
>> test code), implement animation features like attach timelines to properties,
>> event-driven behaviours (through subscriptions for example ...), whatsoever. I
>> am also thinking of a basic physics package ... why not.
> ....
>> Again, what I can write in POV-Sdl, the parser could do it natevly with
>> apropriate evolutions.
> 
> These all sound like great ideas.
> 
> I was worried I might sound negative in my comments, just my experiences with
> artists.
> 
> One of the reasons I like your ideas is that being a developer and extreme long
> time POV-Ray user myself, having more logic expression sounds great for complex
> scene generation.
> 

Hi.

See my last WIP in p.b.s-f (2 posts).

Regards

-- 
L'absence de virus dans ce courrier Ã©lectronique a
Ã©tÃ© vÃ©rifiÃ©e par le logiciel antivirus
Avast.
https://www.avast.com/antivirus

[Tor Olav Kristensen] Re: VSCode Extension - Render Error Output [1487 days 16 hours and 8 minutes ago]

Sat, 12 Mar 2022 00:50:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "kennebel" <jac### [at] kennebelcom> wrote:
> > Hello there!
> >
> > I decided to fork the VSCode extension for POV-Ray (which quit working awhile
> > back due to changes in the system). I got it back up and running, added a few
> > features:
> >
> >
https://marketplace.visualstudio.com/items?itemName=virtual-whirlwind.vscode-povray2
> > https://github.com/VirtualWhirlwind/vscode-povray2
> >
> > While using it on Windows, I've noticed that when there is a scene/syntax issue,
> > I need
> > to open the regular POV-Ray editor to run the file as the command line rendering
> > doesn't give the error message. Is there a 3.7 command line switch/parameter
> > that would put the render errors back to the console that I could capture and
> > show in the VSCode interface?
>
> A very long time ago I used MicroEmacs in MS DOS v6.22. And then I was able to
> make MicroEmacs gather the error messages from the console (when compiling) and
> show them in a separate window (IIRC). So I guess that it is still possible in
> Windows.
>
> In Linux/Unix POV-Ray writes to stderr (and perhaps stdout). You can read more
> about redirecting in BASH here:
> https://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html
>
> NB - What is written here:
> https://www.povray.org/documentation/3.7.0/r3_2.html
> - indicates that one should be able to write something like this:
>
> cat test.pov | povray +I-
>
> I have tested this in BASH with the POV-Ray available in Ubuntu (20.04 ?), but
> unfortunately it does not work.
>
> Also see the comment from c-lipka here:
> https://github.com/POV-Ray/povray/issues/35

I know almost nothing about VS Code, but I have a suspicion that Yong Wang's
answer here is relevant:

https://stackoverflow.com/questions/43007267/how-to-run-a-system-command-from-vscode-extension

It seems to me that his code is dealing with what the executed shell command
outputs to stdout or (and ?) stderr.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[kennebel] Re: VSCode Extension - Render Error Output [1487 days 17 hours and 3 minutes ago]

Fri, 11 Mar 2022 23:55:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Thanks a lot for reviving the extension, but now that I made the switch I
> noticed the pov binary path field and gave its path, so expected one step less
> to make it work just by clicking the pov icon after that but no, I just got the
> info message of the attached capture showing all provided settings. So are we
> expected to create a build task by hand in a json file ?

Woohoo! My first bug report for this project! I don't have a modern mac, so
couldn't test. (also, i wasn't even sure anyone would install/use it, thinking i
was stealing from the previous author) Now that I know someone is, I'll have to
see if i get get that mac mini that is sitting in a box running again.

In the meantime, please feel free to email me (jac### [at] kennebelcom), and we can
sort out what I missed on the Mac side, try some fixes, and get it working again
for you/mac users too!

Thanks everyone for the encouragement, i'll keep poking at the switches to get
the output. I'm sure it will work, just need to sit down and really look at it.
:) I really want to make this extension useful again, and learn a few things
along the way.

[Mr] Re: VSCode Extension - Render Error Output [1487 days 20 hours and 3 minutes ago]

Fri, 11 Mar 2022 20:55:00 GMT

"kennebel" <jac### [at] kennebelcom> wrote:
> Hello there!
>
> I decided to fork the VSCode extension for POV-Ray (which quit working awhile
> back due to changes in the system). I got it back up and running, added a few
> features:
>
> https://marketplace.visualstudio.com/items?itemName=virtual-whirlwind.vscode-povray2
> https://github.com/VirtualWhirlwind/vscode-povray2
>
> While using it on Windows, I've noticed that when there is a scene/syntax issue,
> I need
> to open the regular POV-Ray editor to run the file as the command line rendering
> doesn't give the error message. Is there a 3.7 command line switch/parameter
> that would put the render errors back to the console that I could capture and
> show in the VSCode interface?

Thanks a lot for reviving the extension, but now that I made the switch I
noticed the pov binary path field and gave its path, so expected one step less
to make it work just by clicking the pov icon after that but no, I just got the
info message of the attached capture showing all provided settings. So are we
expected to create a build task by hand in a json file ?

[Mr] Re: VSCode Extension - Render Error Output [1487 days 20 hours and 18 minutes ago]

Fri, 11 Mar 2022 20:40:00 GMT

"kennebel" <jac### [at] kennebelcom> wrote:
> Hello there!
>
> I decided to fork the VSCode extension for POV-Ray (which quit working awhile
> back due to changes in the system). I got it back up and running, added a few
> features:
>
> https://marketplace.visualstudio.com/items?itemName=virtual-whirlwind.vscode-povray2
> https://github.com/VirtualWhirlwind/vscode-povray2
>
> While using it on Windows, I've noticed that when there is a scene/syntax issue,
> I need
> to open the regular POV-Ray editor to run the file as the command line rendering
> doesn't give the error message. Is there a 3.7 command line switch/parameter
> that would put the render errors back to the console that I could capture and
> show in the VSCode interface?

You can also have a look at the Blender POV addon which does pipe everything to
console, and even copies it inside the Blender interactive python console, when
one is open.

[Tor Olav Kristensen] Re: VSCode Extension - Render Error Output [1488 days 1 hour and 43 minutes ago]

Fri, 11 Mar 2022 15:15:00 GMT

"kennebel" <jac### [at] kennebelcom> wrote:
> Hello there!
>
> I decided to fork the VSCode extension for POV-Ray (which quit working awhile
> back due to changes in the system). I got it back up and running, added a few
> features:
>
> https://marketplace.visualstudio.com/items?itemName=virtual-whirlwind.vscode-povray2
> https://github.com/VirtualWhirlwind/vscode-povray2
>
> While using it on Windows, I've noticed that when there is a scene/syntax issue,
> I need
> to open the regular POV-Ray editor to run the file as the command line rendering
> doesn't give the error message. Is there a 3.7 command line switch/parameter
> that would put the render errors back to the console that I could capture and
> show in the VSCode interface?

A very long time ago I used MicroEmacs in MS DOS v6.22. And then I was able to
make MicroEmacs gather the error messages from the console (when compiling) and
show them in a separate window (IIRC). So I guess that it is still possible in
Windows.

In Linux/Unix POV-Ray writes to stderr (and perhaps stdout). You can read more
about redirecting in BASH here:
https://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

NB - What is written here:
https://www.povray.org/documentation/3.7.0/r3_2.html
- indicates that one should be able to write something like this:

cat test.pov | povray +I-

I have tested this in BASH with the POV-Ray available in Ubuntu (20.04 ?), but
unfortunately it does not work.

Also see the comment from c-lipka here:
https://github.com/POV-Ray/povray/issues/35

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: VSCode Extension - Render Error Output [1488 days 11 hours and 38 minutes ago]

Fri, 11 Mar 2022 05:20:00 GMT

hi,

"kennebel" <jac### [at] kennebelcom> wrote:
> > > ... Is there a 3.7 command line switch/parameter
> > > ...
> Thanks for the response. No matter what I try with the settings suggested there,
> nothing ever seems to change during my renders. So sad. Makes building
> supporting apps challenging. :)

have not used all of them (never needed to) but use '-gr' and '-gs', for
instance, routinely.  have you tried those switches "clean", ie just POV-Ray?
if, as I assume, they work, then the problem would seem to be in the VS code
interface or code.

regards, jr.

[kennebel] Re: VSCode Extension - Render Error Output [1488 days 17 hours and 3 minutes ago]

Thu, 10 Mar 2022 23:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "kennebel" <jac### [at] kennebelcom> wrote:
> > ... Is there a 3.7 command line switch/parameter
> > that would put the render errors back to the console that I could capture and
> > show in the VSCode interface?
>
> <https://wiki.povray.org/content/Reference:Text_Output_Options>
>
> (no idea re "VSCode interface")
>
>
> regards, jr.

Thanks for the response. No matter what I try with the settings suggested there,
nothing ever seems to change during my renders. So sad. Makes building
supporting apps challenging. :)

[kennebel] Re: PROOF : Pov Ray Object Oriented Features : a... [1492 days 22 hours and 8 minutes ago]

Sun, 6 Mar 2022 18:50:00 GMT

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
....
> Currently, I am unit-testing my core PROOF code. Then, I will try to write some
> illustrative examples of how to use classes to improve and extend POV obects as
> well as their behaviour. For example, I can imagine classes that helps you
> visualize Bounding Boxes (if useful), place your objects in your scenes (use of
> trace(), which cannot be done outside the parser without rewriting intersection
> test code), implement animation features like attach timelines to properties,
> event-driven behaviours (through subscriptions for example ...), whatsoever. I
> am also thinking of a basic physics package ... why not.
....
> Again, what I can write in POV-Sdl, the parser could do it natevly with
> apropriate evolutions.

These all sound like great ideas.

I was worried I might sound negative in my comments, just my experiences with
artists.

One of the reasons I like your ideas is that being a developer and extreme long
time POV-Ray user myself, having more logic expression sounds great for complex
scene generation.

[Bruno Cabasson] Re: PROOF : Pov Ray Object Oriented Features : a... [1492 days 23 hours and 38 minutes ago]

Sun, 6 Mar 2022 17:20:00 GMT

"kennebel" <jac### [at] kennebelcom> wrote:
> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> > But it is also a weak point because 3D artists are not programmers
> > (to my opinion). So, if the language itself were more 'accessible' to the many,
> > perhaps artists would be less reluctant to dive into POV-Ray. To give it a new
> > interest, making the language itself more 'attractive' would serve POV-Ray's
> > purpose.
>
> I am genuinely curious if you have worked with digital artists before.
>
> 2 jobs ago for me, I ran the IT department for a small digital art studio. Had
> about 25 artists doing 2D and 3D work. For our software inventory we had Maya,
> 3DS Max, Adobe Creative Suite, ZBrush, Unity 3D, and so many plug ins (around
> 200 or so covering effects, pipeline management, and other utilities). The
> company did a mix of legal cases, marketing, movie work (as a secondary
> studio), and other things.
>
> Any conversation with the artists, if it didn't start with how the tool worked
> with their Wacom tablet and special smart pens, was a non-starter. The tablet
> was closest to the artist, keyboard was in between the tablet and monitor (not
> easy to type on, for occasional shortcuts), the mouse was pushed off to the
> side. It was amazing how much work they could do with the smart pen buttons and
> the buttons on the tablet.
>
> Basically at no point will a language change entice the artistic folks
> unfortunately. The artists have tens of thousands of hours on their tablets,
> practically extensions of their will, and all of the plugins available for the
> other tools. Tools like Blender that are similar to what they already use has
> almost no adoption because it lacks the pipeline and plugins.
>
> I really like the direction of your ideas for extending the language. I would
> like to see new changes like this to be a super set of the SDL. Meaning, like
> C++ or Typescript, you can use the classic SDL (c or javascript), or you can use
> the advanced syntax for more complex efforts.

Hi! Thanks for your comments. Indeed.

As a former software engineer in the space industry for 30 years, I did not work
with 3D artists. Just POVing for fun for years (since ... I do not remember) and
having an eye to 3D world, watching tutorials by curiousity and intellectual
challenge.

A few years back, I was thinking about writing some Python classes, close to
Sdl, that could permit you to describe your scenes and, in fine, generate POV
code. The quite new dictionary data structure gave me the idea that it could
eventually be possible to describe classes and  instances with dictionaries in
Sdl itself. So I had it a try.

Currently, I am unit-testing my core PROOF code. Then, I will try to write some
illustrative examples of how to use classes to improve and extend POV obects as
well as their behaviour. For example, I can imagine classes that helps you
visualize Bounding Boxes (if useful), place your objects in your scenes (use of
trace(), which cannot be done outside the parser without rewriting intersection
test code), implement animation features like attach timelines to properties,
event-driven behaviours (through subscriptions for example ...), whatsoever. I
am also thinking of a basic physics package ... why not.

In addition, having MegaPOV's motion blur, UberPOV's unbiased radiosity
(no_cache keyword) would increase the scope of POV-Sdl compared to other 3D
softwares. Also, some practical tools like the old 'spilin' spline generator
would be welcome if shipped (with due credits) with POV-Ray (or integrated to
it).

Again, what I can write in POV-Sdl, the parser could do it natevly with
apropriate evolutions.

Regards

    Bruno

PS : A few time ago, many of us were thinking of GPU computing. This has been
discussed many times.

[kennebel] Re: PROOF : Pov Ray Object Oriented Features : a... [1493 days 15 hours and 13 minutes ago]

Sun, 6 Mar 2022 01:45:00 GMT

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> But it is also a weak point because 3D artists are not programmers
> (to my opinion). So, if the language itself were more 'accessible' to the many,
> perhaps artists would be less reluctant to dive into POV-Ray. To give it a new
> interest, making the language itself more 'attractive' would serve POV-Ray's
> purpose.

I am genuinely curious if you have worked with digital artists before.

2 jobs ago for me, I ran the IT department for a small digital art studio. Had
about 25 artists doing 2D and 3D work. For our software inventory we had Maya,
3DS Max, Adobe Creative Suite, ZBrush, Unity 3D, and so many plug ins (around
200 or so covering effects, pipeline management, and other utilities). The
company did a mix of legal cases, marketing, movie work (as a secondary
studio), and other things.

Any conversation with the artists, if it didn't start with how the tool worked
with their Wacom tablet and special smart pens, was a non-starter. The tablet
was closest to the artist, keyboard was in between the tablet and monitor (not
easy to type on, for occasional shortcuts), the mouse was pushed off to the
side. It was amazing how much work they could do with the smart pen buttons and
the buttons on the tablet.

Basically at no point will a language change entice the artistic folks
unfortunately. The artists have tens of thousands of hours on their tablets,
practically extensions of their will, and all of the plugins available for the
other tools. Tools like Blender that are similar to what they already use has
almost no adoption because it lacks the pipeline and plugins.

I really like the direction of your ideas for extending the language. I would
like to see new changes like this to be a super set of the SDL. Meaning, like
C++ or Typescript, you can use the classic SDL (c or javascript), or you can use
the advanced syntax for more complex efforts.

[jr] Re: VSCode Extension - Render Error Output [1494 days 9 hours and 3 minutes ago]

Sat, 5 Mar 2022 07:55:00 GMT

hi,

"kennebel" <jac### [at] kennebelcom> wrote:
> ... Is there a 3.7 command line switch/parameter
> that would put the render errors back to the console that I could capture and
> show in the VSCode interface?

<https://wiki.povray.org/content/Reference:Text_Output_Options>

(no idea re "VSCode interface")


regards, jr.

[kennebel] VSCode Extension - Render Error Output [1494 days 16 hours and 38 minutes ago]

Sat, 5 Mar 2022 00:20:00 GMT

Hello there!

I decided to fork the VSCode extension for POV-Ray (which quit working awhile
back due to changes in the system). I got it back up and running, added a few
features:

https://marketplace.visualstudio.com/items?itemName=virtual-whirlwind.vscode-povray2
https://github.com/VirtualWhirlwind/vscode-povray2

While using it on Windows, I've noticed that when there is a scene/syntax issue,
I need
to open the regular POV-Ray editor to run the file as the command line rendering
doesn't give the error message. Is there a 3.7 command line switch/parameter
that would put the render errors back to the console that I could capture and
show in the VSCode interface?

[Bruno Cabasson] Re: PROOF : Pov Ray Object Oriented Features : a... [1497 days 17 hours and 8 minutes ago]

Tue, 1 Mar 2022 23:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> > [sorry, I pressed the 'post message' by accident ...]
> > Hi There!
>
> just a couple of comments and questions.
>
>
> > ...
> > After having #include'ed the appropriate definitions (currently, I have :
> > primitives.inc, collections.inc, oocore.inc for the basic OO featues),
>
> I've re-read the post a couple of times, am curious about and try to wrap my
> head round the .. substance.  I think it would be very helpful if you could post
> a zip with the includes and two or three demonstrations of the OO features,
> aimed perhaps at the (snipped, sorry) "3D artists".
>
>
> > I can write this, as a syntactic example without any other interest :
> >
> > [START]
> > // == class MyClass =========================
> > #declare MyClass = class
> > (
> >     "MyClass", // Name of the class
> >     no,        // No parent class
> >     None,
> >     array      // properties
> >     {
> >         array mixed {"property1", TYPES._int_},
> >         array mixed {"property2", TYPES._string_}
> >     },
> >     array    // Methods
> >     {
> >         "method1",
> >         "method2"
> >     }
> > )
> > ... here is a code fragment :
> > describe(Sphere,)
> > #declare my_sphere = new
> > (
> >     Sphere,,
> >     dictionary {.center : 1.2*x, .radius_ : 1}
> > )
> > setmods
> > (
> >     my_sphere,
> >     dictionary
> >     {
> >         .texture_ : pigment {Red},
> >     }
> > )
> > setfinish(my_sphere, finish {specular 0.8 roughness 0.002})
> > setnormal(my_sphere, normal {crackle 2 scale 0.3})
> > dump(my_sphere,)
> > spawn(my_sphere)
> > dump(my_sphere,)
> >
> > And let there be the sphere !!
>
> Q - what is the state of the documentation?  because the above isn't exactly
> "self-descriptive", I feel I'd want a (detailed) reference to hand.
>
> also, as a potential user I think that's a lot of code to go from object
> creation to the "instance".  perhaps the raw OO syntax could/should be hidden
> inside wrappers ("syntactic sugar" :-)).
>
>
> > As such, classes for object have no real interest if you just drop objects in
> > your scene. But, with classes and object-orientedness, one can go further and
> > implement behaviours, design pattens ...
> >
> > This post was quite long, therefore, I'll tell more in a next one.
>
> please.  and some "hands-on" example code perhaps?
>
>
> regards, jr.

Thanks for reading! I did not provide all my stuff because the post was already
very long. It was just to show the principle. My work is in very, very, very
very early stage and barely a POC. I can provide a WIP just so that the examples
work.

Let me work a little more on it, add more comments in the code, and I publish
all I have so far.

Regards

Bruno

[jr] Re: PROOF : Pov Ray Object Oriented Features : a... [1497 days 23 hours and 23 minutes ago]

Tue, 1 Mar 2022 17:35:00 GMT

hi,

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> [sorry, I pressed the 'post message' by accident ...]
> Hi There!

just a couple of comments and questions.

> ...
> After having #include'ed the appropriate definitions (currently, I have :
> primitives.inc, collections.inc, oocore.inc for the basic OO featues),

I've re-read the post a couple of times, am curious about and try to wrap my
head round the .. substance.  I think it would be very helpful if you could post
a zip with the includes and two or three demonstrations of the OO features,
aimed perhaps at the (snipped, sorry) "3D artists".

> I can write this, as a syntactic example without any other interest :
>
> [START]
> // == class MyClass =========================
> #declare MyClass = class
> (
>     "MyClass", // Name of the class
>     no,        // No parent class
>     None,
>     array      // properties
>     {
>         array mixed {"property1", TYPES._int_},
>         array mixed {"property2", TYPES._string_}
>     },
>     array    // Methods
>     {
>         "method1",
>         "method2"
>     }
> )
> ... here is a code fragment :
> describe(Sphere,)
> #declare my_sphere = new
> (
>     Sphere,,
>     dictionary {.center : 1.2*x, .radius_ : 1}
> )
> setmods
> (
>     my_sphere,
>     dictionary
>     {
>         .texture_ : pigment {Red},
>     }
> )
> setfinish(my_sphere, finish {specular 0.8 roughness 0.002})
> setnormal(my_sphere, normal {crackle 2 scale 0.3})
> dump(my_sphere,)
> spawn(my_sphere)
> dump(my_sphere,)
>
> And let there be the sphere !!

Q - what is the state of the documentation?  because the above isn't exactly
"self-descriptive", I feel I'd want a (detailed) reference to hand.

also, as a potential user I think that's a lot of code to go from object
creation to the "instance".  perhaps the raw OO syntax could/should be hidden
inside wrappers ("syntactic sugar" :-)).

> As such, classes for object have no real interest if you just drop objects in
> your scene. But, with classes and object-orientedness, one can go further and
> implement behaviours, design pattens ...
>
> This post was quite long, therefore, I'll tell more in a next one.

please.  and some "hands-on" example code perhaps?

regards, jr.

[Bruno Cabasson] PROOF : Pov Ray Object Oriented Features : an at... [1500 days 5 hours and 3 minutes ago]

Sun, 27 Feb 2022 11:55:00 GMT

[sorry, I pressed the 'post message' by accident ...]
Hi There!

+------------------+
| PART 1 : general |
+------------------+

I am a bit sad to see that the golden age of POV-Ray is behind us. POV-Ray
remains a great thing, still unequaled. My deepest wish concerning it is that it
finds a new interest among the community but also outside it.

A new interest in at least 3 respects.

First, as a powerful language. I found nothing equivalent and THAT compact to
describe scenes. As a language, using POV-ray and taking advantage of all its
syntactic capabilities is all about programming. This is its strength, praised
by all of us. But it is also a weak point because 3D artists are not programmers
(to my opinion). So, if the language itself were more 'accessible' to the many,
perhaps artists would be less reluctant to dive into POV-Ray. To give it a new
interest, making the language itself more 'attractive' would serve POV-Ray's
purpose. That's where my object-oriented attempt with the still embryionic PROOF
 kicks in. I'll explain the main ideas below.

Second, it is an extremely good renderer. Provided you have been POVing for
years, you can generate the best images ever. Now, with modern machines,
rendering time is less of a great concern, even without using GPUs.

Third, POV-Ray lacks all kinds of libraries : objects, materials, templates,
animation oriented features, .... It also lacks on-line tutorials. This could
make it more popular.

I can see one opening towards the 3D people : Blender. There is an interface
between POV-Ray sdl and Blender. Blender is sooo much widespread that it could
help our purpose (and that of Blender also. Presently, I cannot see how.

Also, we still have among us a bunch of masters. They could help promoting if
ever they happend to appear again...


+------------------+
| PART 2 : classes |
+------------------+

Well, that being said, here is a quick glance at PROOF.


    +------------------------+
    | PART 2.1 : sample code |
    +------------------------+

After having #include'ed the appropriate definitions (currently, I have :
primitives.inc, collections.inc, oocore.inc for the basic OO featues), I can
write this, as a syntactic example without any other interest :

[START]
// == class MyClass =========================
#declare MyClass = class
(
    "MyClass", // Name of the class
    no,        // No parent class
    None,
    array      // properties
    {
        array mixed {"property1", TYPES._int_},
        array mixed {"property2", TYPES._string_}
    },
    array    // Methods
    {
        "method1",
        "method2"
    }
)

// Define 2 overloaded constructors used through the 'new()' macro in
"oocore.inc".
// Default constructor, with signature number = 0.
//
// new_MyClass(this, property1, property2)
#macro new_MyClass(this, optional params_dict)
    #ifdef (local.params_array)
        #local this.property1 = check(params_dict.property1, TYPES._int_);
        #local this.property2 = check(params_dict.property2, TYPES._string_);
    #else
        #local this.property1 = 0;
        #local this.property2 = "default string";
    #end
#end

// Overloaded constructor #1, with signature number = 1.
// new_1_MyClass(this, property1, property2, _offset)
#macro new_1_MyClass(this, optional params_dict)
    // By hand : check parameter types, then link methods to the class to get
the instance.
    #local p1 = check(params_dict.property1, TYPES._int_);
    #local p2 = check(params_dict.property2, TYPES._string_);
    #local offset_ = check(params_dict.offset_, TYPES._vector_);

    #local this.property1 = p1 + vlength(offset_);
    #local this.property2 = concat(p2, " ", vstr(5, offset_, ",", 0, 0));
#end


// Instance dump method, used through the 'dump' macro in "oocore.inc".
#macro MyClass_dump(this, indent_level)
    #debug concat(indent[indent_level], "instance of \"", this.class.classname,
"\"\n")
    #debug "{\n"
    #debug concat(indent[indent_level+1], ".class : ", this.class.classname,
"\n")
    #debug concat(indent[indent_level+1], ".property1 : ", str(this.property1,
0, 0), "\n")
    #debug concat(indent[indent_level+1], ".property2 : ", this.property2, "\n")
    #debug concat(indent[indent_level+1], ".method1() : ", this.method1, "\n")
    #debug concat(indent[indent_level+1], ".method2() : ", this.method2, "\n")
    #debug "}\n"
#end


// Default 'method1' method, used through the 'call' macro in oocore.inc".
// MyClass_method1(this, p1, p2)
#macro MyClass_method1(this, optional params_dict)
    #local p1 = check(params_dict.property1, TYPES._int_);
    #local p2 = check(params_dict.property2, TYPES._string_);

    #debug concat("==> ", this.method1, "(p1 = ", str(p1, 0, 0), " (int), p2 =
", p2, " (string))\n")

    #debug "executing ...\n"
    #debug concat("this.property1 = ", str(this.property1, 0, 0), "\n")
    #debug concat("this.property2 = \"", this.property2, "\"\n")

    #debug concat("<== ", this.method1, "\n")
#end


// Overloaded 'method1' method #1, used through the 'call' macro in oocore.inc".
// MyClass_method1_1(this, p1, p2, p3)
#macro MyClass_method1_1(this, optional params_dict)
    #local p1 = check(params_dict.property1, TYPES._int_);
    #local p2 = check(params_dict.property2, TYPES._string_);
    #local p3 = check(params_dict.pigment_, TYPES._pigment_);

    #debug concat("==> ", this.method1, "_1(p1 = ", str(p1, 0, 0), " (int), p2 =
\"", p2, "\" (string), p3 = pigment {})\n")

    #debug "executing ...\n"
    #debug concat("this.property1 = ", str(this.property1, 0, 0), "\n")
    #debug concat("this.property2 = \"", this.property2, "\"\n")

    #debug concat("<== ", this.method1, "\n")
#end

// Default 'method2' method, used through the 'call' macro in oocore.inc".
// MyClass_method2(this, p1)
#macro MyClass_method2(this, optional params_dict)
    #local p1 = check(params_dict.p1, TYPES._vector_);

    #debug concat("==> ", this.method2, "(p1 = <", vstr(3, p1, ", ", 0, 0), ">
(vector)\n")

    #debug "executing ...\n"

    #debug concat("this.property1 = ", str(this.property1, 0, 0), "\n")
    #debug concat("this.property2 = \"", this.property2, "\"\n")

    #debug concat("<== ", this.method2, "\n")
#end
// ===========================================

// Using MyClass
describe(MyClass,)

// Get 2 instances of MyClass, using the 2 provided constructors.
#declare my_instance = new(MyClass, 0, dictionary {.property1 : 0, .property2 :
"text"});
dump(my_instance,)

#declare my_instance2 = new(MyClass, 1, dictionary {.property1 : 0, .property2 :
"text", .offset_ : x + y});
dump(my_instance2, )

// Call all the versions of the overloaded 'method1' method of class 'MyClass'.
call(my_instance.method1,, my_instance, dictionary {.property1 : 0, .property2 :
"text"})
call(my_instance.method1, 1, my_instance, dictionary {.property1 : 0, .property2
: "text", .pigment_ : pigment{Yellow}})

// Call all 'method3' method of class 'MyClass'.
call(my_instance.method2,, my_instance, dictionary {.p1 : <0, 1, 3>})


// == class Derived =========================
#declare Derived = class
(
    "Derived",
    yes,  // has a parent class
    MyClass, // Parent class
    array
    {
        array mixed {"property3", TYPES._vector_} // added property
    },
    array
    {
        "method3" // added method
    }
)

describe(Derived,)

// Instance dump method., used through the 'dump' macro in "oocore.inc".
#macro new_Derived(this, optional params_dict)
    #debug "==> new_Derived()\n"

    super(this,, params_dict)

    #ifdef (local.params_array)
        #local offset_ = check(params_dict.offset_, TYPES._vector_);
    #else
        #local offset_ = 0;
    #end
    #local this.property1 = this.property1 + vlength(offset_);
    #local this.property2 = concat(this.property2, " ", str(2*vlength(offset_),
0, 4));
    #local this.property3 = offset_;

    #debug "<== new_Derived()\n"
#end

#macro Derived_dump(this, indent_level)
    #debug concat(indent[indent_level], "instance of \"", this.class.classname,
"\"\n")
    #debug "{\n"
    #debug concat(indent[indent_level+1], ".class : ", this.class.classname,
"\n")
    #debug concat(indent[indent_level+1], ".property1 : ", str(this.property1,
0, 0), "\n")
    #debug concat(indent[indent_level+1], ".property2 : ", this.property2, "\n")
    #debug concat(indent[indent_level+1], ".property3 : <", vstr(3,
this.property3, ", ", 0, 6), ">\n")
    #debug concat(indent[indent_level+1], ".method1() : ", this.method1, "\n")
    #debug concat(indent[indent_level+1], ".method2() : ", this.method2, "\n")
    #debug concat(indent[indent_level+1], ".method3() : ", this.method3, "\n")
    #debug "}\n"
#end

#macro Derived_method2(this, params_dict)
    #debug "Derived_method2()\n"
#end

#macro Derived_method3(this, params_dict)
    #debug "Derived_method3()\n"
#end
// ===========================================

#declare my_derived_intance = new(Derived,, dictionary {.propery1 : 33,
..property2 : "zorg", .offset_ : <0,1,2>});
dump(my_derived_intance,)


// == class Derived2 =========================
#declare Derived2 = class
(
    "Derived2",
    yes,
    Derived,
    array {}, // no more properties
    array {}  // no more methods
)

describe(Derived2,)

// Instance dump method., used through the 'dump' macro in "oocore.inc".
#macro new_Derived2(this, optional params_dict)
    #debug "==> new_Derived2()\n"

    super(this,, params_dict)

    #debug "<== new_Derived2()\n"
#end

#macro Derived2_dump(this, indent_level)
    #debug concat(indent[indent_level], "instance of \"", this.class.classname,
"\"\n")
    #debug "{\n"
    #debug concat(indent[indent_level+1], ".class : ", this.class.classname,
"\n")
    #debug concat(indent[indent_level+1], ".property1 : ", str(this.property1,
0, 0), "\n")
    #debug concat(indent[indent_level+1], ".property2 : ", this.property2, "\n")
    #debug concat(indent[indent_level+1], ".property3 : <", vstr(3,
this.property3, ", ", 0, 6), ">\n")
    #debug concat(indent[indent_level+1], ".method1() : ", this.method1, "\n")
    #debug concat(indent[indent_level+1], ".method2() : ", this.method2, "\n")
    #debug concat(indent[indent_level+1], ".method3() : ", this.method3, "\n")
    #debug "}\n"
#end

#macro Derived2_method3(this, optional params_dict)
    #debug "Derived2_method3()\n"
#end

// ===========================================

#declare my_derived2_intance = new(Derived2,, dictionary {.property1 : 33,
..property2 : "zorg", .offset_ : <0,1,2>});
dump(my_derived2_intance, 0)
call(my_derived2_intance.method3,, my_derived2_intance,)

#debug concat("isinstance(my_derived2_intance, Derived2) : ",
str(instanceof(my_derived2_intance, Derived2), 0, 0), "\n")
#debug concat("isinstance(my_derived2_intance, Derived) : ",
str(instanceof(my_derived2_intance, Derived), 0, 0), "\n")
#debug concat("isinstance(my_derived2_intance, MyClass) : ",
str(instanceof(my_derived2_intance, MyClass), 0, 0), "\n")

// == class Junk =============================
#declare Junk = class
(
    "Junk",
    yes,
    Derived,
    array {}, // no more properties
    array {}  // no more methods
)

#macro Junk_dump(this, indent_level)
    Derived_dump(this, indent_level)
#end

#macro new_Junk(this, optional params_dict)
    super(this,, params_array)
#end

#debug concat("isinstance(my_derived2_intance, Junk) : ",
str(instanceof(my_derived2_intance, Junk), 0, 0), "\n")

describe(Junk,)

#declare my_junk = new(Junk,,)
dump(my_junk,)

[END]

    +-------------------+
    | PART 2.2 : output |
    +-------------------+

I find all this quite compact. It could be better if the native Sdl had some
specific features. But it does the job as it is. The output of the above code is
teh following :

class MyClass
{
    .classname : MyClass
    .property1 : int
    .property2 : string
    .method1()
    .method2()
}
instance of "MyClass"
{
    .class : MyClass
    .property1 : 0
    .property2 : default string
    .method1() : MyClass_method1
    .method2() : MyClass_method2
}
instance of "MyClass"
{
    .class : MyClass
    .property1 : 1
    .property2 : text 1,1,0,0,0
    .method1() : MyClass_method1
    .method2() : MyClass_method2
}
==> MyClass_method1(p1 = 0 (int), p2 = text (string))
executing ...
this.property1 = 0
this.property2 = "default string"
<== MyClass_method1
==> MyClass_method1_1(p1 = 0 (int), p2 = "text" (string), p3 = pigment {})
executing ...
this.property1 = 0
this.property2 = "default string"
<== MyClass_method1
==> MyClass_method2(p1 = <0, 1, 3> (vector)
executing ...
this.property1 = 0
this.property2 = "default string"
<== MyClass_method2
class Derived
{
    .classname : Derived
    .parent :
        class MyClass
        {
            .classname : MyClass
            .property1 : int
            .property2 : string
            .method1()
            .method2()
        }
    .property3 : vector
    .method3()
}
==> new_Derived()
<== new_Derived()
instance of "Derived"
{
    .class : Derived
    .property1 : 0
    .property2 : default string 0.0000
    .property3 : <0.000000, 0.000000, 0.000000>
    .method1() : MyClass_method1
    .method2() : Derived_method2
    .method3() : Derived_method3
}
class Derived2
{
    .classname : Derived2
    .parent :
        class Derived
        {
            .classname : Derived
            .parent :
                class MyClass
                {
                    .classname : MyClass
                    .property1 : int
                    .property2 : string
                    .method1()
                    .method2()
                }
            .property3 : vector
            .method3()
        }
}
==> new_Derived2()
==> new_Derived()
<== new_Derived()
<== new_Derived2()
instance of "Derived2"
{
    .class : Derived2
    .property1 : 0
    .property2 : default string 0.0000
    .property3 : <0.000000, 0.000000, 0.000000>
    .method1() : MyClass_method1
    .method2() : Derived_method2
    .method3() : Derived2_method3
}
Derived2_method3()
isinstance(my_derived2_intance, Derived2) : 1
isinstance(my_derived2_intance, Derived) : 1
isinstance(my_derived2_intance, MyClass) : 1
isinstance(my_derived2_intance, Junk) : 0
class Junk
{
    .classname : Junk
    .parent :
        class Derived
    .parent :
        class Derived
        {
            .classname : Derived
            .parent :
                class MyClass
                {
                    .classname : MyClass
                    .property1 : int
                    .property2 : string
                    .method1()
                    .method2()
                }
            .property3 : vector
            .method3()
        }
}
==> new_Derived()
<== new_Derived()
instance of "Junk"
{
    .class : Junk
    .property1 : 0
    .property2 : default string 0.0000
    .property3 : <0.000000, 0.000000, 0.000000>
    .method1() : MyClass_method1
    .method2() : Derived_method2
    .method3() : Derived_method3
}

+---------------------------+
| PART 3 : object in scenes |
+---------------------------+

Now, we have classes and some OO features. I went a bit further with objects in
scenes (spheres, boxes, and all others). I designed a set of classes for that
puspose, and the use of them leads to a quite compact code. The definitions are
in a specific include file. As a teaser,, here is a code fragment :

describe(Sphere,)
#declare my_sphere = new
(
    Sphere,,
    dictionary {.center : 1.2*x, .radius_ : 1}
)
setmods
(
    my_sphere,
    dictionary
    {
        .texture_ : pigment {Red},
    }

[ remainder of message truncated in this digest view due to length ]

[Bruno Cabasson] [1500 days 6 hours and 13 minutes ago]

Sun, 27 Feb 2022 10:45:00 GMT

Hi There!

+------------------+
| PART 1 : general |
+------------------+

I am a bit sad to see that the golden age of POV-Ray is behind us. POV-Ray
remains a great thing, still unequaled. My deepest wish concerning it is that it
finds a new interest among the community but also outside it.

A new interest in at least 2 respects.

First, as a powerful language. I found nothing equivalent and THAT compact to
describe scenes. As a language, using POV-ray and taking advantage of all its
syntactic capabilities is all about programming. This is its strength, praised
by all of us. But it is also a weak point because 3D artists are not programmers
(to my opinion). So, if the language itself were more 'accessible' to the many,
perhaps artists would be less reluctant to dive into POV-Ray. To give it a new
interest, making the language itself more 'attractive' would serve POV-Ray's
purpose. That's where my object-oriented attempt with the still embryionic PROOF
 kicks in. I'll explain the main ideas below.

Second, it is an extremely good renderer. Provided you have been POVing for
years, you can generate the best images ever. Now, with modern machines,
rendering time is less of a great concern, even without using GPUs.

Third, POV-Ray lacks all kinds of libraries : objects, materials, templates,
animation oriented features, .... It also lacks on-line tutorials. This could
make it more popular.

I can see one opening towards the 3D people : Blender. There is an interface
between POV-Ray sdl and Blender. Blender is sooo much widespread that it could
help our purpose (and that of Blender also. Presently, I cannot see how.

Also, we still have among us a bunch of masters. They could help promoting if
ever they happend to appear again...


+------------------+
| PART 2 : classes |
+------------------+

Well, that being said, here is a quick glance at PROOF.


    +------------------------+
    | PART 2.1 : sample code |
    +------------------------+

After having #include'ed the appropriate definitions (currently, I have :
primitives.inc, collections.inc, oocore.inc for the basic OO featues), I can
write this, as a syntactic example without any other interest :

[START]
// == class MyClass =========================
#declare MyClass = class
(
    "MyClass", // Name of the class
    no,        // No parent class
    None,
    array      // properties
    {
        array mixed {"property1", TYPES._int_},
        array mixed {"property2", TYPES._string_}
    },
    array    // Methods
    {
        "method1",
        "method2"
    }
)

// Define 2 overloaded constructors used through the 'new()' macro in
"oocore.inc".
// Default constructor, with signature number = 0.
//
// new_MyClass(this, property1, property2)
#macro new_MyClass(this, optional params_dict)
    #ifdef (local.params_array)
        #local this.property1 = check(params_dict.property1, TYPES._int_);
        #local this.property2 = check(params_dict.property2, TYPES._string_);
    #else
        #local this.property1 = 0;
        #local this.property2 = "default string";
    #end
#end

// Overloaded constructor #1, with signature number = 1.
// new_1_MyClass(this, property1, property2, _offset)
#macro new_1_MyClass(this, optional params_dict)
    // By hand : check parameter types, then link methods to the class to get
the instance.
    #local p1 = check(params_dict.property1, TYPES._int_);
    #local p2 = check(params_dict.property2, TYPES._string_);
    #local offset_ = check(params_dict.offset_, TYPES._vector_);

    #local this.property1 = p1 + vlength(offset_);
    #local this.property2 = concat(p2, " ", vstr(5, offset_, ",", 0, 0));
#end


// Instance dump method, used through the 'dump' macro in "oocore.inc".
#macro MyClass_dump(this, indent_level)
    #debug concat(indent[indent_level], "instance of \"", this.class.classname,
"\"\n")
    #debug "{\n"
    #debug concat(indent[indent_level+1], ".class : ", this.class.classname,
"\n")
    #debug concat(indent[indent_level+1], ".property1 : ", str(this.property1,
0, 0), "\n")
    #debug concat(indent[indent_level+1], ".property2 : ", this.property2, "\n")
    #debug concat(indent[indent_level+1], ".method1() : ", this.method1, "\n")
    #debug concat(indent[indent_level+1], ".method2() : ", this.method2, "\n")
    #debug "}\n"
#end


// Default 'method1' method, used through the 'call' macro in oocore.inc".
// MyClass_method1(this, p1, p2)
#macro MyClass_method1(this, optional params_dict)
    #local p1 = check(params_dict.property1, TYPES._int_);
    #local p2 = check(params_dict.property2, TYPES._string_);

    #debug concat("==> ", this.method1, "(p1 = ", str(p1, 0, 0), " (int), p2 =
", p2, " (string))\n")

    #debug "executing ...\n"
    #debug concat("this.property1 = ", str(this.property1, 0, 0), "\n")
    #debug concat("this.property2 = \"", this.property2, "\"\n")

    #debug concat("<== ", this.method1, "\n")
#end


// Overloaded 'method1' method #1, used through the 'call' macro in oocore.inc".
// MyClass_method1_1(this, p1, p2, p3)
#macro MyClass_method1_1(this, optional params_dict)
    #local p1 = check(params_dict.property1, TYPES._int_);
    #local p2 = check(params_dict.property2, TYPES._string_);
    #local p3 = check(params_dict.pigment_, TYPES._pigment_);

    #debug concat("==> ", this.method1, "_1(p1 = ", str(p1, 0, 0), " (int), p2 =
\"", p2, "\" (string), p3 = pigment {})\n")

    #debug "executing ...\n"
    #debug concat("this.property1 = ", str(this.property1, 0, 0), "\n")
    #debug concat("this.property2 = \"", this.property2, "\"\n")

    #debug concat("<== ", this.method1, "\n")
#end

// Default 'method2' method, used through the 'call' macro in oocore.inc".
// MyClass_method2(this, p1)
#macro MyClass_method2(this, optional params_dict)
    #local p1 = check(params_dict.p1, TYPES._vector_);

    #debug concat("==> ", this.method2, "(p1 = <", vstr(3, p1, ", ", 0, 0), ">
(vector)\n")

    #debug "executing ...\n"

    #debug concat("this.property1 = ", str(this.property1, 0, 0), "\n")
    #debug concat("this.property2 = \"", this.property2, "\"\n")

    #debug concat("<== ", this.method2, "\n")
#end
// ===========================================

// Using MyClass
describe(MyClass,)

// Get 2 instances of MyClass, using the 2 provided constructors.
#declare my_instance = new(MyClass, 0, dictionary {.property1 : 0, .property2 :
"text"});
dump(my_instance,)

#declare my_instance2 = new(MyClass, 1, dictionary {.property1 : 0, .property2 :
"text", .offset_ : x + y});
dump(my_instance2, )

// Call all the versions of the overloaded 'method1' method of class 'MyClass'.
call(my_instance.method1,, my_instance, dictionary {.property1 : 0, .property2 :
"text"})
call(my_instance.method1, 1, my_instance, dictionary {.property1 : 0, .property2
: "text", .pigment_ : pigment{Yellow}})

// Call all 'method3' method of class 'MyClass'.
call(my_instance.method2,, my_instance, dictionary {.p1 : <0, 1, 3>})


// == class Derived =========================
#declare Derived = class
(
    "Derived",
    yes,  // has a parent class
    MyClass, // Parent class
    array
    {
        array mixed {"property3", TYPES._vector_} // added property
    },
    array
    {
        "method3" // added method
    }
)

describe(Derived,)

// Instance dump method., used through the 'dump' macro in "oocore.inc".
#macro new_Derived(this, optional params_dict)
    #debug "==> new_Derived()\n"

    super(this,, params_dict)

    #ifdef (local.params_array)
        #local offset_ = check(params_dict.offset_, TYPES._vector_);
    #else
        #local offset_ = 0;
    #end
    #local this.property1 = this.property1 + vlength(offset_);
    #local this.property2 = concat(this.property2, " ", str(2*vlength(offset_),
0, 4));
    #local this.property3 = offset_;

    #debug "<== new_Derived()\n"
#end

#macro Derived_dump(this, indent_level)
    #debug concat(indent[indent_level], "instance of \"", this.class.classname,
"\"\n")
    #debug "{\n"
    #debug concat(indent[indent_level+1], ".class : ", this.class.classname,
"\n")
    #debug concat(indent[indent_level+1], ".property1 : ", str(this.property1,
0, 0), "\n")
    #debug concat(indent[indent_level+1], ".property2 : ", this.property2, "\n")
    #debug concat(indent[indent_level+1], ".property3 : <", vstr(3,
this.property3, ", ", 0, 6), ">\n")
    #debug concat(indent[indent_level+1], ".method1() : ", this.method1, "\n")
    #debug concat(indent[indent_level+1], ".method2() : ", this.method2, "\n")
    #debug concat(indent[indent_level+1], ".method3() : ", this.method3, "\n")
    #debug "}\n"
#end

#macro Derived_method2(this, params_dict)
    #debug "Derived_method2()\n"
#end

#macro Derived_method3(this, params_dict)
    #debug "Derived_method3()\n"
#end
// ===========================================

#declare my_derived_intance = new(Derived,, dictionary {.propery1 : 33,
..property2 : "zorg", .offset_ : <0,1,2>});
dump(my_derived_intance,)


// == class Derived2 =========================
#declare Derived2 = class
(
    "Derived2",
    yes,
    Derived,
    array {}, // no more properties
    array {}  // no more methods
)

describe(Derived2,)

// Instance dump method., used through the 'dump' macro in "oocore.inc".
#macro new_Derived2(this, optional params_dict)
    #debug "==> new_Derived2()\n"

    super(this,, params_dict)

    #debug "<== new_Derived2()\n"
#end

#macro Derived2_dump(this, indent_level)
    #debug concat(indent[indent_level], "instance of \"", this.class.classname,
"\"\n")
    #debug "{\n"
    #debug concat(indent[indent_level+1], ".class : ", this.class.classname,
"\n")
    #debug concat(indent[indent_level+1], ".property1 : ", str(this.property1,
0, 0), "\n")
    #debug concat(indent[indent_level+1], ".property2 : ", this.property2, "\n")
    #debug concat(indent[indent_level+1], ".property3 : <", vstr(3,
this.property3, ", ", 0, 6), ">\n")
    #debug concat(indent[indent_level+1], ".method1() : ", this.method1, "\n")
    #debug concat(indent[indent_level+1], ".method2() : ", this.method2, "\n")
    #debug concat(indent[indent_level+1], ".method3() : ", this.method3, "\n")
    #debug "}\n"
#end

#macro Derived2_method3(this, optional params_dict)
    #debug "Derived2_method3()\n"
#end

// ===========================================

#declare my_derived2_intance = new(Derived2,, dictionary {.property1 : 33,
..property2 : "zorg", .offset_ : <0,1,2>});
dump(my_derived2_intance, 0)
call(my_derived2_intance.method3,, my_derived2_intance,)

#debug concat("isinstance(my_derived2_intance, Derived2) : ",
str(instanceof(my_derived2_intance, Derived2), 0, 0), "\n")
#debug concat("isinstance(my_derived2_intance, Derived) : ",
str(instanceof(my_derived2_intance, Derived), 0, 0), "\n")
#debug concat("isinstance(my_derived2_intance, MyClass) : ",
str(instanceof(my_derived2_intance, MyClass), 0, 0), "\n")

// == class Junk =============================
#declare Junk = class
(
    "Junk",
    yes,
    Derived,
    array {}, // no more properties
    array {}  // no more methods
)

#macro Junk_dump(this, indent_level)
    Derived_dump(this, indent_level)
#end

#macro new_Junk(this, optional params_dict)
    super(this,, params_array)
#end

#debug concat("isinstance(my_derived2_intance, Junk) : ",
str(instanceof(my_derived2_intance, Junk), 0, 0), "\n")

describe(Junk,)

#declare my_junk = new(Junk,,)
dump(my_junk,)

[END]

    +-------------------+
    | PART 2.2 : output |
    +-------------------+

I find all this quite compact. It could be better if the native Sdl had some
specific features. But it does the job as it is. The output of the above code is
teh following :

class MyClass
{
    .classname : MyClass
    .property1 : int
    .property2 : string
    .method1()
    .method2()
}
instance of "MyClass"
{
    .class : MyClass
    .property1 : 0
    .property2 : default string
    .method1() : MyClass_method1
    .method2() : MyClass_method2
}
instance of "MyClass"
{
    .class : MyClass
    .property1 : 1
    .property2 : text 1,1,0,0,0
    .method1() : MyClass_method1
    .method2() : MyClass_method2
}
==> MyClass_method1(p1 = 0 (int), p2 = text (string))
executing ...
this.property1 = 0
this.property2 = "default string"
<== MyClass_method1
==> MyClass_method1_1(p1 = 0 (int), p2 = "text" (string), p3 = pigment {})
executing ...
this.property1 = 0
this.property2 = "default string"
<== MyClass_method1
==> MyClass_method2(p1 = <0, 1, 3> (vector)
executing ...
this.property1 = 0
this.property2 = "default string"
<== MyClass_method2
class Derived
{
    .classname : Derived
    .parent :
        class MyClass
        {
            .classname : MyClass
            .property1 : int
            .property2 : string
            .method1()
            .method2()
        }
    .property3 : vector
    .method3()
}
==> new_Derived()
<== new_Derived()
instance of "Derived"
{
    .class : Derived
    .property1 : 0
    .property2 : default string 0.0000
    .property3 : <0.000000, 0.000000, 0.000000>
    .method1() : MyClass_method1
    .method2() : Derived_method2
    .method3() : Derived_method3
}
class Derived2
{
    .classname : Derived2
    .parent :
        class Derived
        {
            .classname : Derived
            .parent :
                class MyClass
                {
                    .classname : MyClass
                    .property1 : int
                    .property2 : string
                    .method1()
                    .method2()
                }
            .property3 : vector
            .method3()
        }
}
==> new_Derived2()
==> new_Derived()
<== new_Derived()
<== new_Derived2()
instance of "Derived2"
{
    .class : Derived2
    .property1 : 0
    .property2 : default string 0.0000
    .property3 : <0.000000, 0.000000, 0.000000>
    .method1() : MyClass_method1
    .method2() : Derived_method2
    .method3() : Derived2_method3
}
Derived2_method3()
isinstance(my_derived2_intance, Derived2) : 1
isinstance(my_derived2_intance, Derived) : 1
isinstance(my_derived2_intance, MyClass) : 1
isinstance(my_derived2_intance, Junk) : 0
class Junk
{
    .classname : Junk
    .parent :
        class Derived
    .parent :
        class Derived
        {
            .classname : Derived
            .parent :
                class MyClass
                {
                    .classname : MyClass
                    .property1 : int
                    .property2 : string
                    .method1()
                    .method2()
                }
            .property3 : vector
            .method3()
        }
}
==> new_Derived()
<== new_Derived()
instance of "Junk"
{
    .class : Junk
    .property1 : 0
    .property2 : default string 0.0000
    .property3 : <0.000000, 0.000000, 0.000000>
    .method1() : MyClass_method1
    .method2() : Derived_method2
    .method3() : Derived_method3
}

+---------------------------+
| PART 3 : object in scenes |
+---------------------------+

Now, we have classes and some OO features. I went a bit further with objects in
scenes (spheres, boxes, and all others). I designed a set of classes for that
puspose, and the use of them leads to a quite compact code. The definitions are
in a specific include file. As a teaser,, here is a code fragment :

describe(Sphere,)
#declare my_sphere = new
(
    Sphere,,
    dictionary {.center : 1.2*x, .radius_ : 1}
)
setmods
(
    my_sphere,
    dictionary
    {
        .texture_ : pigment {Red},
    }
)

[ remainder of message truncated in this digest view due to length ]

[Chris Cason] Re: C++ version [1565 days 12 hours and 20 minutes ago]

Fri, 24 Dec 2021 04:37:35 GMT

On 18/12/2021 05:31, Alessio Sangalli wrote:
> Hello, what C++ version does the POV-Ray community want to target for 
> the future? I see POV_CPP11_SUPPORTED that as far as I were able to 
> understand is only used to define POVMS_NULLPTR, but older compilers are 
> supported too anyway.
> 
> Is there any reason to continue to support compilers older than C++11? 
> If we could just assume C++11 (or better, C++17) several sections of the 
> code could be rewritten to take advantage of new features of the 
> anguage. For example, I'd start with using constexpr instead of #define 
> in a lot of cases; kinda of a low hanging fruit, but type checking for 
> constants is in my opinion worth having in the 2020's.

This is a question best answered by Christoph Lipka, however I'll add my 
(informal) opinion, and that is with 4.0 we're quite open to changes 
like this. The main constraint (if it is even a constraint) is the 
availability of free, quality compilers that meet the C++11 or C++17 
standards on all the platforms that we target.

-- Chris

[Dick Balaska] Re: How to build console version [1569 days and 7 minutes ago]

Mon, 20 Dec 2021 16:50:41 GMT

On 12/16/2021 6:00 PM, Alessio Sangalli wrote:
> Hello I am trying to mess with the POV-Ray source code.
> 
> Right now I am on a Window machine and I have Visual Studios 2015 AND 
> 2019. Unfortunately I am not an expert of this environment. I would like 
> to compile the console version of the program (I honestly never use the 
> GUI anyway).

To build the console version, you have to configure the modules. Ok, 
it's been a while for me so I don't remember the nomenclature.
There is a dialog box with checkboxes to select the modules to use. i.e. 
jpeg, boost_time, etc.  One will be called GUI, uncheck that.  One will 
be called console, check that.  Then recompile.  You will get build 
errors, but the error is quite specific about what you have to fix to 
move on. Something like enabling _CONSOLE in file ../../blah.h

dik

[Kenneth] Re: How to build console version [1569 days 7 hours and 58 minutes ago]

Mon, 20 Dec 2021 09:00:00 GMT

Alessio Sangalli <man### [at] gmailcom> wrote:
>
> Right now I am on a Window machine and I have Visual Studios 2015 AND
> 2019. Unfortunately I am not an expert of this environment. I would like
> to compile the console version of the program (I honestly never use the
> GUI anyway).
> ...
> Nevermind, it was just easier to open a Kubuntu virtual machine and I
> compiled POV-Ray effortlessly.
>

Congratulations for getting the compiling to successfully work.

I am a long-time user of POV-Ray on Windows, with its native GUI, but I know
almost nothing about Ubuntu OR even how to compile programs. I assume that you
are now running your compiled version IN Windows.

Some questions:
1) Does the compiled program have to be run in the Kubuntu virtual-machine
environment in order to work, or does it run successfully in the native Windows
environment? Or both?

2) Does Kubuntu also allow a GUI to be built for such a compiled version of
POV-Ray? If so, does the resulting program then have to be run in the Kubuntu
environment?

Sorry if my questions might be naive ones; but there are those of us here who
would like to compile POV-Ray from its source code to run on Windows, but don't
know how (because of all of the complicated DLLs required, etc.) I am also
thinking of several 'forks' of POV-Ray that are currently not compiled for
Windows, like William Pokorny's  'povr' branch.

[Alessio Sangalli] C++ version [1571 days 22 hours and 26 minutes ago]

Fri, 17 Dec 2021 18:31:15 GMT

Hello, what C++ version does the POV-Ray community want to target for 
the future? I see POV_CPP11_SUPPORTED that as far as I were able to 
understand is only used to define POVMS_NULLPTR, but older compilers are 
supported too anyway.

Is there any reason to continue to support compilers older than C++11? 
If we could just assume C++11 (or better, C++17) several sections of the 
code could be rewritten to take advantage of new features of the 
anguage. For example, I'd start with using constexpr instead of #define 
in a lot of cases; kinda of a low hanging fruit, but type checking for 
constants is in my opinion worth having in the 2020's.

[Alessio Sangalli] Re: How to build console version [1572 days 13 hours and 11 minutes ago]

Fri, 17 Dec 2021 03:46:49 GMT

On 16-Dec-21 15:00, Alessio Sangalli wrote:
> Hello I am trying to mess with the POV-Ray source code.
> 
> Right now I am on a Window machine and I have Visual Studios 2015 AND 
> 2019.

Nevermind, it was just easier to open a Kubuntu virtual machine and I 
compiled POV-Ray effortlessly.

Thanks!

[Alessio Sangalli] How to build console version [1572 days 17 hours and 58 minutes ago]

Thu, 16 Dec 2021 23:00:05 GMT

Hello I am trying to mess with the POV-Ray source code.

Right now I am on a Window machine and I have Visual Studios 2015 AND 
2019. Unfortunately I am not an expert of this environment. I would like 
to compile the console version of the program (I honestly never use the 
GUI anyway).

My questions are:
1) which branch should I really use:
   remotes/origin/3.7-stable
   remotes/origin/HEAD -> origin/master
   remotes/origin/autobuild/alpha_v380
   remotes/origin/autobuild/experimental
   remotes/origin/autobuild/freetype
   remotes/origin/autobuild/tokenizer
   remotes/origin/autobuild/v3.8.0-alpha
   remotes/origin/experimental/freetype
   remotes/origin/feature/advanced_diffuse
   remotes/origin/feature/colour_model
   remotes/origin/feature/tonemapping
   remotes/origin/housekeeping/prebuild_dir
   remotes/origin/latest-stable
   remotes/origin/master
   remotes/origin/release/v3.7.0
   remotes/origin/release/v3.8.0

I tried 3.7-stable but I got all sorts of issues migrating from the old 
"solution"; I then tried release/v3.8.0 but if I try to compile the 
console version:

1>------ Skipped Build: Project: boost_date_time, Configuration: Debug 
Win32 ------
1>Project not selected to build for this solution configuration
2>------ Build started: Project: console, Configuration: Debug Win32 ------
2>LINK : fatal error LNK1104: cannot open file 
'C:\dev\povray\windows\vs2015\bin32\lib\libboost_date_time32d.lib'
========== Build: 0 succeeded, 1 failed, 21 up-to-date, 1 skipped ==========

(this is after I specified _CONSOLE in syspovconfig.h)

at this point even the GUI version would work but it complains I have to 
use /INSTALL, then I was able to make it start but it still wants more 
DLL's, and I would very much like to stay with a command line console 
version.

Thank you

[m steiger] Re: How to start POV-Ray from Delphi ! [1577 days 9 hours and 48 minutes ago]

Sun, 12 Dec 2021 07:10:00 GMT

"m.steiger" <mar### [at] hotmailcom> wrote:
> For all Delphi programmers who want to render their 3d scenery with PovRay -
> here is a sample code of how to start PovRay from your 3d application.
> Of course, before rendering, you have to export your own PovRay data file first

Oh, unfortunately there are many annoying line breaks in the post. Therefore you
find the source code in the attachment in the current version again.

[m steiger] How to start POV-Ray from Delphi ! [1587 days and 43 minutes ago]

Thu, 2 Dec 2021 16:15:00 GMT

For all Delphi programmers who want to render their 3d scenery with PovRay -
here is a sample code of how to start PovRay from your 3d application.
Of course, before rendering, you have to export your own PovRay data file first
;-)

Hint: Save following source code in file 'PovRayStarter.dpr'.
-------------------------------------------------------------

//********************************************************************
// Project File:   PovRayStarter.dpr  v1.02   2021-01-03
// A Delphi console example program for starting 'PovRay rendering'.
// PovRayStarter.exe tested with:  Delphi-6 release with      8.704 Bytes
//                                 Delphi-Sydney-CE with  1.162.752 Bytes
// Ref.:
https://www.delphipraxis.net/35458-wie-ruft-man-povray-aus-einem-programm-heraus-auf.html
//********************************************************************
{$D+,L+,Y+,R+,S+,Q+,O-,C+}   // debug
{$D-,L-,Y-,R-,S-,Q-,O-,C-}   // release

{$APPTYPE CONSOLE}

program PovRayStarter;

uses  SysUtils, ShellApi, Windows, Registry;

const
  NL = #13#10;   // NewLine = carriage return + linefeed
  PovRayStartCommand36 = 'C:/Program Files/POV_Ray/POV-Ray 3.6/bin/pvengine.exe
+FP ';
  PovRayStartCommand37 = 'C:/Program Files/POV_Ray/POV-Ray 3.7/bin/pvengine.exe
';
  // set your individual start command here:
  PovRayStartCommand37b=
'E:\Programming_Tools\POV_Ray\POV-Ray_3.7\bin\pvengine32-sse2.exe';

var
  povStartCommand, povStartParams: string;

//*********************************************************
// Gets a string value from the registry from the given root and sub key.
// Converts integer value to a string
// Returns '', if the sub key or value name are unknown.
//---------------------------------------------------------
function GetRegistryString (const rootKey: HKEY;
                            const subKey, name: string): string;
var
  reg: TRegistry;            // registry access object
  valueInfo: TRegDataInfo;   // info about registry value
begin
  Result := '';
  reg := TRegistry.Create;
  try
    reg.RootKey := rootKey;
    if reg.OpenKeyReadOnly (subKey)
    then if reg.GetDataInfo (name, valueInfo)  // check if registry value is
string or integer
    then begin
      case valueInfo.RegData of
        // string value: just return it
        rdString, rdExpandString:   Result := reg.ReadString (name);
        // integer value: convert to string
        rdInteger:   Result := IntToStr (reg.ReadInteger(name));
      end;
    end;
  finally
    reg.CloseKey;
    reg.Free;
  end;
end;
//*********************************************************
// get start command of PovRay Renderer
//---------------------------------------------------------
procedure GetPovRayStartCommand;
var si: integer;
begin
  povStartCommand := paramStr(1);
  if povStartCommand = ''
  then begin
    povStartCommand := GetRegistryString (HKEY_CLASSES_ROOT
                    , '\Applications\pvengine.exe\shell\open\Command', '');
    if povStartCommand <> ''
    then begin
      // cut text after 'pvengine.exe"'
      si := pos('pvengine.exe"', povStartCommand);
      if si > 0
      then delete (povStartCommand, si+13, 999);
    end;
  end;
  if povStartCommand = ''
  then povStartCommand := PovRayStartCommand36;
  if povStartCommand = '' then
    povStartCommand := PovRayStartCommand37;
  writeln ('Start command of PovRay program : '#13#10,'  ', povStartCommand);
end;
//*********************************************************
// execute Windows application
// input:    name: string     application name
//           param: string    application start parameters
// result:   boolean          =true application started
//           errorCode        e.g.  2 = ERROR_FILE_NOT_FOUND
// see:
https://docwiki.embarcadero.com/RADStudio/Sydney/en/Input-Output_Errors
// examples: started := RunApplication ('pvengine.exe', '/RENDER example.pov');
//           started := RunApplication ('ReadMe.txt', '');  // view text file
//           RunApplication ('notepad', 'info.txt');        // view text file
with notePad
//           RunApplication ('Explorer', 'C:\');            // start windows
explorer
//---------------------------------------------------------
function RunApplication (const name, param: string): boolean;
var   errorCode: cardinal;
begin
  writeln (NL,'try starting PovRay with command...', NL, name, param);

  errorCode := ShellExecute (0, 'open', PChar(name), PChar(param), nil,
SW_SHOWNORMAL);

  result := (errorCode = 0) or (errorCode = 42);
  if result
  then writeln ('  successfully started ')
  else writeln ('RunApplication:  ', NL
               ,'  can not start application ''', name+param, '''' + NL
               ,'  error code = ' + IntToStr(errorCode));

  // german info from Delphi-Praxis:
  //   https://www.delphipraxis.net/126563-shellexecute-error.html
end;
//*********************************************************
// start rendering of povray scene
//---------------------------------------------------------
procedure StartPovRayRendering (const povfilename: string);
var
  result: boolean;
begin
  povStartParams := ' /EDIT ' + povfilename
                  + ' /RENDER ' + povfilename
                  + ' +FN';   // PNG output see
http://www.povray.org/documentation/view/3.6.1/219/

  // try to start PovRay 3.6
  result := RunApplication (povStartCommand, povStartParams);
  if not result
  // try to start PovRay 3.7b
  then RunApplication (PovRayStartCommand37b, povStartParams);
end;
//*********************************************************
// create povray test scene file
//---------------------------------------------------------
procedure SavePovRayTestFile (const povfilename: string);
var  pov: text;
begin
  Assign (pov, povfilename);
  ReWrite (pov);
  writeln (pov, '// File: ' + povfilename, NL
              , 'camera {location -3*z}', NL
              , 'light_source {<9,9,-9> 1 parallel}', NL
              , 'sphere {0 1 pigment {rgb<1,1,0.5>}}', NL);
  Close (pov);
end;
//*********************************************************
const
  povFilename = 'Test1.pov';
begin
  writeln (NL, '=== PovRayStarter v1.02 ===', NL);
  SavePovRayTestFile (povFilename);
  GetPovRayStartCommand;
  StartPovRayRendering (povFilename);
  sleep(7000);
end.

[tth] Re: Time for a Rant [1690 days 2 hours and 23 minutes ago]

Sat, 21 Aug 2021 14:35:02 GMT

On 8/21/21 1:47 PM, Le_Forgeron wrote:

>> Speaking of which, did you know just what a clusterf*** time and date
>> related programming in C/C++ is? Or, as a matter of fact, in general?
>>
>>
> 
> You talked too much of UTC, and forgot to mention TAI.
> 
> 
> And if you want even more fun: GPS clock... it is yet another offset.
> 
      A lot of gory details :
             http://www.catb.org/esr/time-programming/

-- 
+-------------------------------------------------------------------+
|                      sphinx of black quartz, judge my vow.        |
+-------------------------------------------------------------------+

[Le Forgeron] Re: Time for a Rant [1690 days 5 hours and 10 minutes ago]

Sat, 21 Aug 2021 11:47:15 GMT

Le 17/08/2021 Ã  00:45, clipka a Ã©critÂ :
> I haven't done a good old rant lately, have I?
> 
> Well, this is the time, and this is the day.
> 
> Speaking of which, did you know just what a clusterf*** time and date
> related programming in C/C++ is? Or, as a matter of fact, in general?
> 
> 

You talked too much of UTC, and forgot to mention TAI.


And if you want even more fun: GPS clock... it is yet another offset.

[clipka] Re: Time for a Rant [1694 days and 1 minute ago]

Tue, 17 Aug 2021 16:56:24 GMT

Am 17.08.2021 um 12:35 schrieb Thorsten:
> On 17.08.2021 00:45, clipka wrote:
>> I haven't done a good old rant lately, have I?
>>
>> Well, this is the time, and this is the day.
>>
>> Speaking of which, did you know just what a clusterf*** time and date 
>> related programming in C/C++ is? Or, as a matter of fact, in general?
> 
> Well, guess why a date and time function never made it into POV-Ray 
> before. I am pretty sure there was a patch around 20 or so years ago for 
> this, with these, and a few more problems back then...

*Everything* was a clusterf*** of portability issues back then. Boost, 
and later C++11, took care of a lot of that.

Unfortunately, the C++ standard committee only made a half-hearted 
attempt at doing something about the date and time related stuff back then.

As a matter of fact I think C++20's functionality would make it 
reasonably easy. But for a long-lived project like POV-Ray, requiring 
C++20 now is at least half a decade too soon.

[clipka] Re: Time for a Rant [1694 days and 10 minutes ago]

Tue, 17 Aug 2021 16:47:20 GMT

Am 17.08.2021 um 11:10 schrieb William F Pokorny:

> If you've not found it, there is a relatively popular C++ header only 
> 'date.h' (and 'tz.*') for c++11/C++14/C++17. I looked at it briefly, but 
> then bailed for a simpler c/unix only path.

Fun fact: "Slightly modified versions of "date.h" and "tz.h" were voted 
into the C++20 working draft at the Jacksonville FL meeting on 2018-03-17"

So it can't be too terrible.

> Aside: What code analysis tool is picking up the thread safe issues for 
> you?

That would be GitHub's CodeQL. What it actually does (among other 
things) is pick up the use of functions that are deemed inherently unsafe.

So, for instance, if I were to build a wall of mutexes and lock guards 
around the function, CodeQL would still bicker about it.

And rightly so, because even such a Fort Knox approach only works if 
there's a guarantee that the functions aren't called from anywhere else. 
So it's not the optimum approach.

[Thorsten] Re: Time for a Rant [1694 days 6 hours and 22 minutes ago]

Tue, 17 Aug 2021 10:35:42 GMT

On 17.08.2021 00:45, clipka wrote:
> I haven't done a good old rant lately, have I?
> 
> Well, this is the time, and this is the day.
> 
> Speaking of which, did you know just what a clusterf*** time and date 
> related programming in C/C++ is? Or, as a matter of fact, in general?

Well, guess why a date and time function never made it into POV-Ray 
before. I am pretty sure there was a patch around 20 or so years ago for 
this, with these, and a few more problems back then...

Thorsten

[William F Pokorny] Re: Time for a Rant [1694 days 7 hours and 48 minutes ago]

Tue, 17 Aug 2021 09:10:08 GMT

On 8/16/21 6:45 PM, clipka wrote:
> I haven't done a good old rant lately, have I?
> 
> Well, this is the time, and this is the day.
> 
:-) At least you're still tossing jokes.

After a time... My test C/C++ file names became various obscene phrases.

If you've not found it, there is a relatively popular C++ header only 
'date.h' (and 'tz.*') for c++11/C++14/C++17. I looked at it briefly, but 
then bailed for a simpler c/unix only path.

See: https://github.com/HowardHinnant/date

My take is the license would allow POV-Ray to use it.

---
Aside: What code analysis tool is picking up the thread safe issues for 
you? I became aware these existed as I played - and I tried to handle 
them/be immune(where parser only use), but, I didn't got so far as to 
add a mutex variable & a lock guard. Suppose that would be the 
paranoid/safe approach - these time related functions are all going to 
be slow in any case - but, I didn't go that far.

Bill P.

[clipka] Re: Time for a Rant [1694 days 8 hours and 9 minutes ago]

Tue, 17 Aug 2021 08:48:14 GMT

Am 17.08.2021 um 01:32 schrieb jr:

>> Granted, there's an interface to get timezone XY. ...
> 
> would 'tzset(3)' help?  (POSIX + thread-safe, but *NIX only, I guess)

No; that would be the way to determine the timezone name on Unix, with 
which you could then get a boost timezone. But, as you already noticed, 
it doesn't exist on Windows.


Also, boost date_time timezones aren't really an ideal solution anyway. 
They presume that the local time rules are immutable for any given 
locale, when in reality they can vary.

When the `TZ` environment variable is NOT set, or specifies the time 
zone indirectly via reference to a filename, the standard C functions 
(on POSIX systems) are capable of using a far more flexible system to 
determine which time offset was in effect for which point in time.

[jr] Re: Time for a Rant [1694 days 17 hours and 23 minutes ago]

Mon, 16 Aug 2021 23:35:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> I haven't done a good old rant lately, have I?
> Well, this is the time, and this is the day.

commiserations.  (though I did enjoy the read, some of it was tinged with
sympathy. :-))

> ...
> Granted, there's an interface to get timezone XY. ...

would 'tzset(3)' help?  (POSIX + thread-safe, but *NIX only, I guess)

regards, jr.

[clipka] Time for a Rant [1694 days 18 hours and 12 minutes ago]

Mon, 16 Aug 2021 22:45:56 GMT

I haven't done a good old rant lately, have I?

Well, this is the time, and this is the day.

Speaking of which, did you know just what a clusterf*** time and date 
related programming in C/C++ is? Or, as a matter of fact, in general?


Okay, boost's date_time library worked. Boost seems to have a tendency 
to do that, I do give them that.

Yes, it did work... for UTC. That's GMT for the old timers. Except it's 
not. Or it may be. Depends on who's talking. Could be plain UT instead 
for all we know. Also, historically, for some time GMT-based dates 
started at noon. So nobody in their sane mind should really use GMT to 
denote universal points in time. Not that there is such thing as a 
universal point in time anyway (Thanks, Einstein)... but I think I might 
be digressing a little... so, boost worked nicely for UTC.

But if, instead of UTC, you want to play with times and dates in local 
time, you need to use time zones.

Now there _is_ a timezone sub-library in boost date_time, and it is 
designed to integrate neatly with the rest of date_time, so no big deal, 
right?


Except, said timezone library provides NO way to get the timezone 
matching the system's locale. Because that, I guess, would be too common 
a use case, and would make life too easy for programmers. You know how 
you have to present challenges to zoo animals every once in a while so 
they don't get mentally ill? I think it's the same for programmers. 
Seems like boost got that message.

Granted, there's an interface to get timezone XY. But good luck 
detecting that the system's locale uses timezone XY in the first place. 
Sure, every operating system worth its price (or even just a fraction 
thereof) provides a function to get the name of the current timezone. 
But of course some OSes don't bother to follow any of the established 
standards (of which there are multiple of course) for timezone names, 
except their own. (Where have I seen this before? And what OS could I 
possibly be looking at?) And of course that's precisely the one boost 
refuses to recognize (which also deserves a reproachful stare).

Now you _could_ possibly use some other functions to try and detect the 
offset from UTC, and then construct an ad-hoc time zone from that. But 
that won't work reliably for dates other than today, because this won't 
tell you whether Daylight Savings Time is in effect today, nor whether 
that may be different from the day in question.


Speaking of DST - did you know that there are entire databases of what 
Daylight Savings Time rules were in effect in what country in what time 
period? And your operating system probably has one of those. Which may 
or may not be up-to-date, but it's the best we can get.


So why not ditch boost date_time altogether, and use good old standard C 
library functions. If _those_ don't know the proper time zone, and 
whether DST applied, or will apply (presumably, based on current rules), 
for any given date you name, nobody does.

There are a couple of standard functions defined to convert between a 
semi-universal "point in time" data type (`time_t`) and a data type 
holding Gregorian date and time data (`tm`).


Except, those functions are not thread-safe. Which is kind of a 
deal-breaker in a multithreaded application. And besides, our automated 
source code analysis tool would bicker about it, for exactly that reason.


Well, fortunately there are thread-safe alternatives provided by the 
operating systems.

Phew.

Not that there is any universal standard for them. Because, again, that 
would be too easy.

So where e.g. POSIX systems have `localtime_r()` to replace 
`localtime()`. Windows has `_localtime_s()`.

Not to be confused with `localtime_s()`, which is a standard function in 
C (C11 and later to be precise). Which still hasn't been adopted into 
any C++ standard. And has a different parameter order than Windows' 
`_localtime_s()` - because zoo animals I guess.

But those functions do exist, for each of the original thread-unsafe C 
functions.


So there's functions to convert to and from Gregorian date and time, in 
both local time and UTC variants.


Except for the conversion _from_ Gregorian time. There's only one 
variant for those. Guess which one.

If you guessed that variant was the UTC one - because it's easier to 
implement, since the point-in-time data type is also universal rather 
than local time - then you may guess again.


Yeah. No way to convert a Gregorian date and UTC time to that 
point-in-time type, which is also UTC based.

Well, there is such a function on sone Unixoid systems, and oddly enough 
for onece GNU and BSD agree there. But not on Windows. And not even on 
generic POSIX.

*Sigh*.

Now you _could_ roll your own function to do this computation. Dig up a 
formula to convert any Gregorian date to a linear day (say, Modified 
Julian Date), subtract an offset so that you get a zero for 1970-01-01, 
multiply by 24*60*60, add the time, and shove that value into `time_t`. 
Because that's how that type works, right? POSIX time. Seconds since 
1970-01-01, 00:00 UTC.

Well, not so fast. Because nowhere does the C or C++ standard mandate 
that `time_t` actually work that way.

And as a matter of fact on most systems it doesn't. Though that's 
actually all the better for the computations.

Because leap seconds. Did you ever spare a thought for them?
Not all days are created equal. Some are 24*60*60+1 seconds long. And 
some could be, theoretically, as short as 24*60*60-1 seconds.
The former tends to happen about every one or two years, and the 
astronomy boffins decide when it's time to insert another one.

To compute how many seconds have actually elapsed since any given date 
and time, we'd have to consult a database of leap seconds.

Without that, our homebrew formula would only work if days were always 
24*60*60 seconds long. And fortunately that's exactly how POSIX time 
_actually_ works: Its base unit isn't seconds at all. It's calendar 
days, except that they're scaled by a factor of 24*60*60, and with time 
of day in seconds added.


Except on systems where it isn't. Which use POSIX-ish time _including_ 
leap seconds. And while they're rare, they still exist. Or, at least 
hypothetically, systems where `time_t` runs faster than seconds. Or 
slower; even that could be conceivable without violating the C standard. 
So if we need to resort to such homebrew math, we should at least 
implement a check on start-up to verify that the point-in-time data type 
is in fact genuine POSIX time.


Fortunately we only need a homebrew function for one of those Gregorian 
Date conversions...


... as log as we don't care about dates before 1970.


Because, as it turns out, on Windows those functions report an error for 
any point in time earlier than 1970-01-01 00:00 UTC. Or at least that's 
what the documentation claims. In reality, you can't even rely on that: 
A couple of hours before are fine, too. But no more than that.

On Unix at least there only seems to be some wonkiness for a very 
specific 1-second interval around that time, namely 1969-12-31 23:59:59 
UTC. Because apparently someone thought that value would make for a nice 
choice to signal an error. (Did I mention my zoo animal hypothesis?)


So, yay. Hooray for date and time manipulation in C/C++.

I can't wait till the day we require C++20 to build POV-Ray. That's the 
time and day when things will get...
... better? Well, different, anyway.

[clipka] Re: OpenEXR 3.x issues - call to arms [1740 days 7 hours and 6 minutes ago]

Fri, 2 Jul 2021 09:51:45 GMT

Am 02.07.2021 um 02:39 schrieb Ton:

> Hallo Christoph, just created two pull requests. I hope everything on my side
> was done OK, first time I've done this.

No formal complaints from my side - again, thanks!

There's one remaining issue that needs to be ironed out, and I've got a 
few suggestions for additional changes that you could also throw in 
along the way. See my comments to the v3.7 pull request (most also apply 
to v3.8).

As for the "git-technical" side, this should be fairly straightforward: 
All you'll have to do is push additional commits to the corresponding 
branches of your repo copy, and the pull requests should automatically 
pick those up and update themselves accordingly.


Christoph

[clipka] Re: OpenEXR 3.x issues - call to arms [1740 days 14 hours and 54 minutes ago]

Fri, 2 Jul 2021 02:04:08 GMT

Am 02.07.2021 um 02:39 schrieb Ton:

> Hallo Christoph, just created two pull requests. I hope everything on my side
> was done OK, first time I've done this.

Thanks - as for the "git technical" side, the pull requests look rock-solid.

There may be some issue with the suggested changes though - they don't 
seem to build properly on Windows. I'll try to make time tomorrow to 
have a closer look at what might be going on. (Also, no Unix test build 
triggered for the v3.7.0 version, but that's entirely on me.)

[Ton] Re: OpenEXR 3.x issues - call to arms [1740 days 16 hours and 18 minutes ago]

Fri, 2 Jul 2021 00:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 15.06.2021 um 06:29 schrieb Ton:
>
> > So that seems to be working. What is the best way forward with the changed
> > files, ax_check_openexr.m4, povray.cpp and openexr.cpp?
>
> Thanks, much appreciated!
>
> Ideally, you'd set up a Git pull request for the `POV-Ray/povray`
> repository, based on the `release/v3.7.0` branch (NOT `master`); and if
> you feel like it, do the same based on the `release/v3.8.0` branch as
> well (again NOT `master`), but I reckon it should be easy to port the
> change over to v3.8 once it's in the Git repo.
>
> If Git is not your sort of thing, please attach the files (complete - no
> diffs please!) to a post over at `povray.binaries.programming`,
> mentioning in the post what version you took the original files from.
> Ideally someone else can take it from there and turn it into a pull
> request or two - if not, I'll probably be able to find some time to take
> it from there myself eventually.

Hallo Christoph, just created two pull requests. I hope everything on my side
was done OK, first time I've done this.

Cheers
Ton.

[clipka] Re: OpenEXR 3.x issues - call to arms [1757 days 4 hours and 6 minutes ago]

Tue, 15 Jun 2021 12:51:41 GMT

Am 15.06.2021 um 06:29 schrieb Ton:

> So that seems to be working. What is the best way forward with the changed
> files, ax_check_openexr.m4, povray.cpp and openexr.cpp?

Thanks, much appreciated!

Ideally, you'd set up a Git pull request for the `POV-Ray/povray` 
repository, based on the `release/v3.7.0` branch (NOT `master`); and if 
you feel like it, do the same based on the `release/v3.8.0` branch as 
well (again NOT `master`), but I reckon it should be easy to port the 
change over to v3.8 once it's in the Git repo.

If Git is not your sort of thing, please attach the files (complete - no 
diffs please!) to a post over at `povray.binaries.programming`, 
mentioning in the post what version you took the original files from. 
Ideally someone else can take it from there and turn it into a pull 
request or two - if not, I'll probably be able to find some time to take 
it from there myself eventually.

[Ton] Re: OpenEXR 3.x issues - call to arms [1757 days 12 hours and 28 minutes ago]

Tue, 15 Jun 2021 04:30:00 GMT

Persistence of Vision(tm) Ray Tracer Version 3.7.0.9.unofficial (g++ 9 @
x86_64-pc-linux-gnu)
  OpenEXR 2.3.0 and IlmBase 2.3.0, Copyright (c) 2002-2011 Industrial Light &
Magic.
  ldd unix/povray
        libIlmImf-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmImf-2_3.so.24
(0x00007fd918405000)
        libHalf.so.24 => /lib/x86_64-linux-gnu/libHalf.so.24
(0x00007fd9183c0000)
        libIex-2_3.so.24 => /lib/x86_64-linux-gnu/libIex-2_3.so.24
(0x00007fd91839f000)
        libIlmThread-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmThread-2_3.so.24
(0x00007fd917902000)

  OpenEXR 3.1.0-dev and Imath 3.1.0-dev, Copyright (c) Contributors to the
OpenEXR Project.
  ldd unix/povray
        libOpenEXR-3_1.so.29 => /usr/local/lib/libOpenEXR-3_1.so.29
(0x00007f7266ba5000)
        libIlmThread-3_1.so.29 => /usr/local/lib/../lib/libIlmThread-3_1.so.29
(0x00007f7266108000)
        libImath-3_1.so.29 => /usr/local/lib/../lib/libImath-3_1.so.29
(0x00007f72660b3000)
        libIex-3_1.so.29 => /usr/local/lib/../lib/libIex-3_1.so.29
(0x00007f7266032000)


Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.11272893.unofficial
(g++ 9 @ x86_64-pc-linux-gnu)
  OpenEXR 2.3.0 and IlmBase, Copyright (c) 2002-2011 Industrial Light & Magic.
  ldd unix/povray
        libIlmImf-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmImf-2_3.so.24
(0x00007fa2290b8000)
        libHalf.so.24 => /lib/x86_64-linux-gnu/libHalf.so.24
(0x00007fa229073000)
        libIex-2_3.so.24 => /lib/x86_64-linux-gnu/libIex-2_3.so.24
(0x00007fa229052000)
        libIlmThread-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmThread-2_3.so.24
(0x00007fa2285e1000)


So that seems to be working. What is the best way forward with the changed
files, ax_check_openexr.m4, povray.cpp and openexr.cpp?

[clipka] POV-Ray v3.8 backing up a bit [1762 days 7 hours and 11 minutes ago]

Thu, 10 Jun 2021 09:47:02 GMT

Hi folks,

this is a heads-up for all of you who are faithfully working on 
derivatives of POV-Ray - be it qtpovray, the mac port, or what-have-you.

We're currently preparing to enter the beta phase of POV-Ray v3.8; 
however, in order to do so, we will _not_ continue from the current 
master, but rather back up a bit, to the last commit before we 
integrated the overhauled tokenizer/scanner into the parser. To help you 
more easily find that commit in question (85db57d9), we've tagged it as:

     `nexus-v3.8-v4.0`

Also, v3.8 development will _not_ continue in the `master` branch, but 
rather a dedicated branch, `release/v3.8.0` (which already exists and is 
currently ahead of The Nexus, but will be backed up and branch off soon).

Note that besides reverting to the old parser, this will also revert 
back to the use of the boost-thread and boost-system libraries.


We recommend that you _do_ keep all the work you've done since The 
Nexus, as the current state of v3.8 will live on under the moniker v4.0.

There's nothing fundamentally wrong with the changes we introduced since 
The Nexus - we just won't be able to get them to a clean state as fast 
as we'd like to, and we'd probably have to break backward compatibility 
more than we'd be comfortable with in a v3.x release.

[Bald Eagle] Re: Another call to arms [1763 days 5 hours and 53 minutes ago]

Wed, 9 Jun 2021 11:05:00 GMT

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

> There may be a few others.

Don't know enough about the details, but am placing this here due to the
potential issues with the current implementation of parse_string

http://news.povray.org/608967ad%241%40news.povray.org

RL slowing me down, so input and output maybe be sparse.

[clipka] Re: OpenEXR 3.x issues - call to arms [1765 days 9 hours and 23 minutes ago]

Mon, 7 Jun 2021 07:35:10 GMT

Am 07.06.2021 um 04:36 schrieb Ton:

> Hi clipka, I'll have a look at this. I hope that installing openexr 3 will go
> alright and when that's done I can start telling povray to use then new openexr.

Thanks, much appreciated!

[Ton] Re: OpenEXR 3.x issues - call to arms [1765 days 14 hours and 18 minutes ago]

Mon, 7 Jun 2021 02:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 04.06.2021 um 02:06 schrieb Bald Eagle:
> > I am excellent at asking about or stating the obvious, so...
> >
> > Presumably you have seen these (?):
> >
> >
https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md
>
> Nope.
>
> > https://github.com/aforsythe/IlmBase
>
> That repo has been inactive since 2012.
>
>
> As I mentioned, I haven't looked too deep into this yet. And there's
> other stuff I have on my plate at the moment, which I can't delegate as
> easily.
>
> So if anyone could step up and take over this task - from digging up
> info like the above, to actually implementing the necessary fixes - that
> would be terrific.

Hi clipka, I'll have a look at this. I hope that installing openexr 3 will go
alright and when that's done I can start telling povray to use then new openexr.

Cheers
Ton.

[Bald Eagle] Re: Another call to arms [1765 days 18 hours and 58 minutes ago]

Sun, 6 Jun 2021 22:00:00 GMT

I can make a very small scene to demonstrate the issue with the radial pattern,
although I think the extant thread is kinda self-explanatory, and WFP agrees
with the proposed mathematical solution.

All the other things have to deal with source code I haven't looked through or
would likely be able to competently suggest code solutions for.

So here is a list of what I have found / can remember:

creating an array of arrays, and then trying to access an uninitialized element
of that data structure.
https://news.povray.org/5b83c8ab%241%40news.povray.org


A declare without the leading # works
http://news.povray.org/povray.general/thread/%3Cweb.5d8f1cd3fe1f4a21e462584c0%40news.povray.org%3E/?mtop=428173&moff=5

radial pattern
http://news.povray.org/web.5dabcdf0e43f3c684eec112d0%40news.povray.org

suggested fix (coded in SDL function syntax)
#declare Angle = function (XX,ZZ) {atan2 (XX, ZZ)-(pi/2)}
#declare Adjusted = function (XX,ZZ) {select (Angle(XX,ZZ),  Angle(XX,ZZ)+tau,
Angle(XX, ZZ))}
#declare FreqPhase = function (XX, ZZ, F, P) {mod ((P*tau+Adjusted (XX, ZZ))*F,
tau)/tau}
#declare Radial = function (XX, ZZ, F, P) {select (XX*ZZ,  FreqPhase
(XX,ZZ,F,P), 0, FreqPhase (XX,ZZ,F,P))}


project some light through an image
map
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5d101e19377950ae4eec112d0%40news.povray.org%3E/

blend_gamma typo
http://news.povray.org/povray.beta-test/thread/%3C6022887b%241%40news.povray.org%3E/

Icosahedron include
http://news.povray.org/povray.binaries.images/thread/%3C87muh7xgh9.fsf%40munyer.com%3E/?ttop=429414&toff=50

dictionary crash
http://news.povray.org/povray.general/thread/%3CXnsAD0BC42BCF8Aseed7%40news.povray.org%3E/?mtop=433766

normals
http://news.povray.org/povray.binaries.images/thread/%3C5f830726%40news.povray.org%3E/

spiral patterns
https://news.povray.org/5f6c87f2%241%40news.povray.org

no_image
https://news.povray.org/povray.general/thread/%3Cweb.5e7944321f97b21e393d37fe0%40news.povray.org%3E/?ttop=430126&moff=8


cutaway_textures
https://news.povray.org/web.5e3385d55a7390894eec112d0%40news.povray.org

There may be a few others.

[jr] Re: Another call to arms [1767 days 6 hours and 48 minutes ago]

Sat, 5 Jun 2021 10:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> note that I have not included another, older patch for alpha.10064268.  from
> 19.2.2019, correcting missing 'std::' prefixes (but you released a newer version
> for that).

>> By the way, one thing that makes this all the more helpful, is that
>> newsgroup messages posted during my hiatus until somewhen in 2020 are
>> currently cumbersome to access for me, as the news server refuses to
>> tell me what's written in them.

<http://news.povray.org/povray.beta-test/thread/%3C5c6b8351%241%40news.povray.org%3E/>

(forgot..)


regards, jr.

[jr] Re: Another call to arms [1767 days 7 hours and 48 minutes ago]

Sat, 5 Jun 2021 09:10:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.06.2021 um 01:03 schrieb jr:
>
> > I can provide three patches if thought useful.  the following clipped from the
> > build script:
>
> Probably.
>
> Beware that when collecting patches, it is my understanding that they
> only work if the file in question hasn't been changed otherwise, so it
> would be important to note what version of POV-Ray they were designed for.

yes.  I do use version specific sub-directories, so stuff is always kept
together.

note that I have not included another, older patch for alpha.10064268.  from
19.2.2019, correcting missing 'std::' prefixes (but you released a newer version
for that).

regards, jr.

[clipka] Re: Another call to arms [1767 days 8 hours and 54 minutes ago]

Sat, 5 Jun 2021 08:03:29 GMT

Am 04.06.2021 um 22:13 schrieb clipka:

> Now, if we want those fixes to make their way into official POV-Ray, 
> some steps need to happen - all essentially boiling down to getting the 
> information to a place and into a format where it can be more easily 
> managed:

By the way, one thing that makes this all the more helpful, is that 
newsgroup messages posted during my hiatus until somewhen in 2020 are 
currently cumbersome to access for me, as the news server refuses to 
tell me what's written in them.

(No, re-scanning the headers doesn't solve the problem, it only makes it 
worse. Which is why in a few select newsgroups I have lost any trace of 
messages between late 2018 and early 2020 entirely, even the header 
information.)

[clipka] Re: Another call to arms [1767 days 9 hours and 3 minutes ago]

Sat, 5 Jun 2021 07:54:34 GMT

Am 05.06.2021 um 01:03 schrieb jr:

> I can provide three patches if thought useful.  the following clipped from the
> build script:

Probably.

Beware that when collecting patches, it is my understanding that they 
only work if the file in question hasn't been changed otherwise, so it 
would be important to note what version of POV-Ray they were designed for.

In this particular case, it seems rather evident though that it would be 
alpha.10064268.

> # note p.bugreports: WFP 13.8.2020 "alpha.10064268 undef behaviour".
> patch --verbose -p0 < ${CWD}/patch20200813
> # note p.general: WFP 19.9.2020 "povray vs uberpov am3".
> patch --verbose -p0 < ${CWD}/patch20200919
> # note p.beta-test: WFP 21.4.2021 cf ingo, dict copy.
> patch --verbose -p0 < ${CWD}/patch20210421

[jr] Re: Another call to arms [1767 days 17 hours and 53 minutes ago]

Fri, 4 Jun 2021 23:05:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> there's other stuff that needs to be done, which should be easy to
> delegate, at least partially:
>
> During my absence, I gather other people have stepped up and done some
> error diagnosis and coming up with fixes. At least Bill's name has come
> up a couple of times.
> ...
> (3) For errors that have been diagnosed, and for which a solution has
> already been found, it might need to be wise to also add them to the
> issue tracker. More importantly, however, the solution has to be placed
> in a place and into a form that makes it easy to "import" it into the
> POV-Ray codebase.
> ...
> I'm aware that might not be everyone's favorite format, but maybe you
> folks can team up, with someone producing diffs and someone else
> bringing them into Git? (I myself am terrible at working with diffs, so
> don't expect me to touch them except with a 10 foot stick.)
> ...
> I'm grateful for anyone willing to put time and effort into this, so
> that POV-Ray v3.8 gets the bugfixes it deserves. Every little bit helps.

I can provide three patches if thought useful.  the following clipped from the
build script:

# note p.bugreports: WFP 13.8.2020 "alpha.10064268 undef behaviour".
patch --verbose -p0 < ${CWD}/patch20200813
# note p.general: WFP 19.9.2020 "povray vs uberpov am3".
patch --verbose -p0 < ${CWD}/patch20200919
# note p.beta-test: WFP 21.4.2021 cf ingo, dict copy.
patch --verbose -p0 < ${CWD}/patch20210421

(I think there's at least one more "already fixed" for which I didn't make one)


regards, jr.

[clipka] Another call to arms [1767 days 20 hours and 44 minutes ago]

Fri, 4 Jun 2021 20:13:28 GMT

Hi folks,

there's other stuff that needs to be done, which should be easy to 
delegate, at least partially:

During my absence, I gather other people have stepped up and done some 
error diagnosis and coming up with fixes. At least Bill's name has come 
up a couple of times.

Now, if we want those fixes to make their way into official POV-Ray, 
some steps need to happen - all essentially boiling down to getting the 
information to a place and into a format where it can be more easily 
managed:


(1) Information on errors not yet diagnosed, currently spread across 
countless threads on multiple newsgroups, needs to be collected in one 
central place, where the status of each issue can be easily tracked and 
updated, and the error itself easily referenced.

Before I went hiding, the ideal place for that was the Issues section on 
GitHub (https://github.com/POV-Ray/povray/issues).

If you want to help me help you help us all and get those bugs fixed, I 
guess that's still the best place. I don't currently have the energy to 
dig through old threads and sift the information out there, but I guess 
some of you folks could help out with that.

Ideally, the prcess of collecting that information would involve 
"distilling it down" to a simple test case, with a minimalistic scene 
and concise description. Plus a link to the newsgroup thread for reference.


(2) In a similar vein, information on errors already diagnosed, but 
still without a suggested solution, also need to be collected and 
"distilled".

Again I would suggest the issues tracker on GitHub. I'd recommend to put 
the description of symptoms into the issue description proper, and add 
the diagnostic findings as a comment.


(3) For errors that have been diagnosed, and for which a solution has 
already been found, it might need to be wise to also add them to the 
issue tracker. More importantly, however, the solution has to be placed 
in a place and into a form that makes it easy to "import" it into the 
POV-Ray codebase.

Before I went hiding, the ideal format for that would have been a Git 
Pull Request.

I'm aware that might not be everyone's favorite format, but maybe you 
folks can team up, with someone producing diffs and someone else 
bringing them into Git? (I myself am terrible at working with diffs, so 
don't expect me to touch them except with a 10 foot stick.)

A single pull request per issue would be preferable, and changes should 
be based on a recent version from the master branch.


Two important things I'd like to note:

(A) Make sure to coordinate with others, in case there's more than one 
person to pick up this gauntlet.

(B) Be prepared for feedback that may sound rejecting - it is generally 
not meant that way. Whoever will review the error report or proposed 
solution _will_ be thankful for the time and effort you're putting into 
it. And they _will_ be even more thankful for any _additional_ time and 
effort you might be willing to give in case they find a snag with the 
proposed solution. Software developers just generally tend to not be 
very good at conveying such sentiments.


Am I scaring you away already?
I hope I'm not.

I'm grateful for anyone willing to put time and effort into this, so 
that POV-Ray v3.8 gets the bugfixes it deserves. Every little bit helps.

[clipka] Re: OpenEXR 3.x issues - call to arms [1767 days 21 hours and 42 minutes ago]

Fri, 4 Jun 2021 19:15:16 GMT

Am 04.06.2021 um 02:06 schrieb Bald Eagle:
> I am excellent at asking about or stating the obvious, so...
> 
> Presumably you have seen these (?):
> 
>
https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md

Nope.

> https://github.com/aforsythe/IlmBase

That repo has been inactive since 2012.


As I mentioned, I haven't looked too deep into this yet. And there's 
other stuff I have on my plate at the moment, which I can't delegate as 
easily.

So if anyone could step up and take over this task - from digging up 
info like the above, to actually implementing the necessary fixes - that 
would be terrific.

[Bald Eagle] Re: OpenEXR 3.x issues - call to arms [1768 days 16 hours and 48 minutes ago]

Fri, 4 Jun 2021 00:10:00 GMT

I am excellent at asking about or stating the obvious, so...

Presumably you have seen these (?):

https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md

https://github.com/aforsythe/IlmBase

[clipka] Re: OpenEXR 3.x issues - call to arms [1768 days 17 hours and 14 minutes ago]

Thu, 3 Jun 2021 23:43:39 GMT

Am 03.06.2021 um 15:32 schrieb jr:

>> Fix the Unix build process to do the right kind of version checking
>> and pulling-in of libraries (primarily relevant files:
>> `unix/configure.ac` and `unix/config/ax_check_openexr.m4`). The test for
>> the actual `IlmImf` library would have to be changed, to test for
>> `OpenEXR` instead if the version number detected is 3.0 or higher; also
>> in that case, a test for the `Imath` library would have to be performed,
>> which we currently don't have because it was effectively implicit when
>> OpenEXR was present.
> 
> confused by your point (2) since 'Imath' is part of version 2.2.0 (and 1.7.1)
> already.

I'm confused by it all, too. At any rate, the math portions are no 
longer found (even when fixing the IlmImf->OpenEXR thing), and that has 
to be fixed.

 From all I've read on the internet, one thing seems quite obvious: 
Those math portions are no longer part of an accompanying library, but a 
library that - at least at this point - constitutes an entirely 
independent project. And I've found talk about it having been "renamed" 
(whatever that means) from `IlmBase` to `Imath`.


It's an ideal job to be delegated: I'm just as confuzzled by it all as 
anyone else.

[jr] Re: OpenEXR 3.x issues - call to arms [1769 days 3 hours and 23 minutes ago]

Thu, 3 Jun 2021 13:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> my knowledge of the autotools is limited, ...

and so are my reading and comprehension, at times, evidently.


> Fix the Unix build process to do the right kind of version checking
> and pulling-in of libraries (primarily relevant files:
> `unix/configure.ac` and `unix/config/ax_check_openexr.m4`). The test for
> the actual `IlmImf` library would have to be changed, to test for
> `OpenEXR` instead if the version number detected is 3.0 or higher; also
> in that case, a test for the `Imath` library would have to be performed,
> which we currently don't have because it was effectively implicit when
> OpenEXR was present.

confused by your point (2) since 'Imath' is part of version 2.2.0 (and 1.7.1)
already.


regards, jr.

[jr] Re: OpenEXR 3.x issues - call to arms [1769 days 7 hours and 58 minutes ago]

Thu, 3 Jun 2021 09:00:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Hi everyone,
>
> anyone trying to compile POV-Ray with a modern version of OpenEXR - i.e.
> 3.0.0 or higher - will have noticed that we're having some snag there.
>
> The reason behind this is that some time in the past, Industrial Light
> and Magic (who had kicked off the OpenEXR thingumajig) had transferred
> the whole shebang to the public, who picked up the ball and ran with it
> like crazy.
>
> Now, in March this year, this transfer has left its mark to the
> structure of the project itself, leading to two major changes:
>
> (1) The OpenEXR library, which used to be named `IlmImf` (for Intustrial
> Light and Magic Image Format), has now officially been renamed to `OpenEXR`.
>
> (2) An accompanying library, providing low-level mathematical stuff,
> like a 16-bit floating-point data type, that used to go by the moniker
> `IlmBase`, has been renamed to `Imath`.
>
> This breaks all our builds, because those are not the libraries we are
> looking for.
>
> And someone needs to fix this.

my knowledge of the autotools is limited, but a quick look in 'unix/config'
shows that various macros test for the various libs, and 'ax_check_openexr.m4'
uses 'pkg-config' to do its thing.  looks like as long as 'pkg-config' is
up-to-date, only actual changed names of header files should impact.


> I think Lovecraft must have had premonitions of the POV-Ray parser code...

:-)


regards, jr.

[clipka] OpenEXR 3.x issues - call to arms [1769 days 19 hours and 12 minutes ago]

Wed, 2 Jun 2021 21:46:09 GMT

Hi everyone,

anyone trying to compile POV-Ray with a modern version of OpenEXR - i.e. 
3.0.0 or higher - will have noticed that we're having some snag there.

The reason behind this is that some time in the past, Industrial Light 
and Magic (who had kicked off the OpenEXR thingumajig) had transferred 
the whole shebang to the public, who picked up the ball and ran with it 
like crazy.

Now, in March this year, this transfer has left its mark to the 
structure of the project itself, leading to two major changes:

(1) The OpenEXR library, which used to be named `IlmImf` (for Intustrial 
Light and Magic Image Format), has now officially been renamed to `OpenEXR`.

(2) An accompanying library, providing low-level mathematical stuff, 
like a 16-bit floating-point data type, that used to go by the moniker 
`IlmBase`, has been renamed to `Imath`.

This breaks all our builds, because those are not the libraries we are 
looking for.

And someone needs to fix this.


I presume it's more a matter of diligence, that requires a bit of 
understanding how an Automake-based build process works, but other than 
that will hopefully not need deep insight into the bowels of POV-Ray 
itself. And it also needs someone who can test any fixes before checking 
them in - which I can't, because my Linux Fu is limited, and the Linux 
machine I have convenient access to doesn't have OpenEXR 3 installed.

What I *think* needs to be done, is the following:

* Fix the Unix build process to do the right kind of version checking 
and pulling-in of libraries (primarily relevant files: 
`unix/configure.ac` and `unix/config/ax_check_openexr.m4`). The test for 
the actual `IlmImf` library would have to be changed, to test for 
`OpenEXR` instead if the version number detected is 3.0 or higher; also 
in that case, a test for the `Imath` library would have to be performed, 
which we currently don't have because it was effectively implicit when 
OpenEXR was present.

* Fix whatever needs fixing to make sure our OpenEXR handling source 
file (in v3.8 that would be `source/base/image/openexr.cpp` includes 
whatever files need including. Maybe we need to include different files 
if OpenEXR 3.x is installed. Maybe we just need to somehow adjust the 
include paths. I'm not sure yet. I haven't dug that deep.

* Fix `source/base/povray.cpp` to pull in the proper version information 
header files for the two libraries; again, you may need to change them, 
or maybe you don't.

* (optional) While you're at it, you might also want to concoct a 
mechanism by which to decide (depending on version number) whom to 
credit as copyright holders, and what internet address to refer to. 
Maybe also pull version information from the libraries via function 
calls (as we do for other libs; but note the comment saying that such 
function is unavailable in older versions). And maybe split up the 
credit into two chunks, one for IlmImf/OpenEXR and the other for 
IlmBase/Imath, as the libs are now fully separate projects.

* IMPORTANT: In all you do, make sure that the whole smash pretty much 
behaves as before (except for maybe improvements to the copyright 
notice) unless OpenEXR 3.0.0 or higher is indeed installed.

* If you're familiar with Git, submit your changes as a pull request to 
the `master` branch in the repo.

The issues affect both v3.8 and v3.7, so you're not done yet:

* Do all of the above again for the `v3.7.0` branch, starting from 
scratch. Whatever you did to fix v3.8, the same approach should also 
work for v3.7, and the changes won't be much different. But the two 
versions have grown too far apart to try and do anything that involves 
merges. They'd bite you in the arse for trying. You figured out what 
needed to be done, so you can do it again.


There. Now for the $0.000.000 question:

Any takers?


I know I could do it myself, but I'd prefer to spare my energy (which is 
limited, as we've seen) and time for the work that still needs to be 
done in POV-Ray's deep, deep gory bowels, where I dare not send anyone 
else, lest they be devoured by the abominations that lurk there. You 
know, the parser. The thing that software developers tell their children 
bedtime stories about when they're refusing to go to sleep. The thing 
that goes "bump" in the night `#if` you don't put an `#end` to it in 
time. The thing that scares you shitless when you meet it at night in a 
dark alleyway...

I think Lovecraft must have had premonitions of the POV-Ray parser code...

[Tor Olav Kristensen] Re: paper written by Nathan Kopp about photon ma... [1823 days 15 hours and 8 minutes ago]

Sat, 10 Apr 2021 01:50:00 GMT

"Mr" <nomail@nomail> wrote:
>...
> Thanks for the file !

No problem.


> I have a profane feeling that many of the statements made
> in the paper are no longer relevant as of POV 3.8 aren't they?
>...

I haven't had time to read it yet, so I don't know.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Mr] Re: paper written by Nathan Kopp about photon ma... [1824 days 5 hours and 8 minutes ago]

Fri, 9 Apr 2021 11:50:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > >
> > > The Wayback Machine at archive.org is your friend.
> >
> > Do you happen to know what app will display this file? At the top, it says
> > %!PS-Adobe-3.0
> > ....and the next line says
> > %%Creator: PSCRIPT.DRV Version 4.0
> >
> > Looks like a Postscript file(?)
> >
> > Btw, I actually thought I had a copy of Nathan Kopp's paper in some form,
> > downloaded long ago; but no luck in my file searches.
>
>
> Those that have a postscript printer could just try to "drop" or copy the file
> to the printer to get a printout.
>
> Some Linux distribution have a ps2pdf utility installed that can convert the
> postscript file to a PDF file. See the attached PDF file, that has been
> converted that way.
>
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k

Thanks for the file ! I have a profane feeling that many of the statements made
in the paper are no longer relevant as of POV 3.8 aren't they?
Some pov/branch developer review where he would strike out all solved issues  or
changed behaviours may save some energy. would a lot remain useful information?

[Tor Olav Kristensen] Re: paper written by Nathan Kopp about photon ma... [1824 days 13 hours and 23 minutes ago]

Fri, 9 Apr 2021 03:35:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> >
> > The Wayback Machine at archive.org is your friend.
>
> Do you happen to know what app will display this file? At the top, it says
> %!PS-Adobe-3.0
> ....and the next line says
> %%Creator: PSCRIPT.DRV Version 4.0
>
> Looks like a Postscript file(?)
>
> Btw, I actually thought I had a copy of Nathan Kopp's paper in some form,
> downloaded long ago; but no luck in my file searches.

Those that have a postscript printer could just try to "drop" or copy the file
to the printer to get a printout.

Some Linux distribution have a ps2pdf utility installed that can convert the
postscript file to a PDF file. See the attached PDF file, that has been
converted that way.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[ingo] Re: paper written by Nathan Kopp about photon ma... [1824 days 20 hours and 4 minutes ago]

Thu, 8 Apr 2021 20:54:13 GMT

in news:web.606f6696d017da6b1f9dae3025979125@news.povray.org Bald Eagle 
wrote:

> You might be
> able to use an office app in windows...   ?
> 

Nothing thats available by default. Here's a list of tools
https://extension.nirsoft.net/ps

Ingo

[Bald Eagle] Re: paper written by Nathan Kopp about photon ma... [1824 days 20 hours and 33 minutes ago]

Thu, 8 Apr 2021 20:25:00 GMT

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.606f3f85d017da6bd98418916e066e29@news.povray.org Kenneth
> wrote:
>
> > Do you happen to know what app will display this file? At the top, it
> > says %!PS-Adobe-3.0
> >
>
> https://www.ghostscript.com/

The inbuilt "document viewer" in Linux Mint opens it as well.   You might be
able to use an office app in windows...   ?

[ingo] Re: paper written by Nathan Kopp about photon ma... [1824 days 21 hours and 7 minutes ago]

Thu, 8 Apr 2021 19:50:17 GMT

in news:web.606f3f85d017da6bd98418916e066e29@news.povray.org Kenneth
wrote: 

> Do you happen to know what app will display this file? At the top, it
> says %!PS-Adobe-3.0
> 

https://www.ghostscript.com/

[Kenneth] Re: paper written by Nathan Kopp about photon ma... [1824 days 23 hours and 18 minutes ago]

Thu, 8 Apr 2021 17:40:00 GMT

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

>
> The Wayback Machine at archive.org is your friend.

Do you happen to know what app will display this file? At the top, it says
%!PS-Adobe-3.0
....and the next line says
%%Creator: PSCRIPT.DRV Version 4.0

Looks like a Postscript file(?)

Btw, I actually thought I had a copy of Nathan Kopp's paper in some form,
downloaded long ago; but no luck in my file searches.

[Bald Eagle] Re: paper written by Nathan Kopp about photon ma... [1825 days 20 hours and 18 minutes ago]

Wed, 7 Apr 2021 20:40:01 GMT

"elma96" <nomail@nomail> wrote:

> Does anyone here maybe still have a copy of it or knows  how to acquire it?
> I would aprreciate  it.

The Wayback Machine at archive.org is your friend.

[elma96] paper written by Nathan Kopp about photon mapping [1825 days 20 hours and 33 minutes ago]

Wed, 7 Apr 2021 20:25:00 GMT

Hallo,

on this webseite:
http://www-f9.ijs.si/~matevz/docs/MegaPov/megapov.html#photons
is mentioned that Nathan Kopp wrote a paper about photon maps.

Quoting:
"The paper is called Simulating Reflective and Refractive Caustics in POV-Ray
Using a Photon Map, and you can download it in zipped postscript format at
http://nathan.kopp.com/nk_photons.zip (size: about 800 KB)."

Unfortunately this website is no longer available and I can't find this
Zip-file.

Does anyone here maybe still have a copy of it or knows  how to acquire it?
I would aprreciate  it.

Regards
Elma

[elma96] Photons refraction/reflection implementation sou... [1827 days 19 hours and 8 minutes ago]

Mon, 5 Apr 2021 21:50:00 GMT

Hallo, I need help on finding the source code file for the implementation of
refraction/reflection while using photons.

As far as I understand the current Implementation, when a photon hits an object
with both reflection and refraction on, two photons are produced, one is
reflected and the other is refracted.

This seems to be too simple for my application and I may need to implement a
better equation to estimate a fraction for photons refracted and reflected.

Regards

[Thorsten] Re: Set small values to 0. [2046 days 2 hours and 14 minutes ago]

Sun, 30 Aug 2020 14:43:38 GMT

The SPEC 2017 code is a beta of 3.7 where the source file comments had 
not been updated yet.

On 30.08.2020 06:58, DonF wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Awaking this morning though, had a question in my head whether the above
>> statement really true? I doubt you are really running v3.7 - or at least
>> any official version of v3.7 because your output has the line:
> 
> 
> The SPEC 2017 benchmark documentation indicates v3.7, but the SPEC code
> itself is still documented as being version 3.6, as indicated from the
> below comments from the quadrics.cpp. But it looks like a common issue
> between 3.6 and 3.7, unless the issue is resolved elsewhere in the newer
> version.
> 
> 
> /****************************************************************************
>   *               quadrics.cpp
>   *
>   * This module implements the code for the quadric shape primitive.
>   *
>   * from Persistence of Vision(tm) Ray Tracer version 3.6.
>   * Copyright 1991-2003 Persistence of Vision Team
>   * Copyright 2003-2009 Persistence of Vision Raytracer Pty. Ltd.
>   *---------------------------------------------------------------------------
>   * NOTICE: This source code file is provided so that users may experiment
>   * with enhancements to POV-Ray and to port the software to platforms other
>   * than those supported by the POV-Ray developers. There are strict rules
>   * regarding how you are permitted to use this file. These rules are contained
>   * in the distribution and derivative versions licenses which should have been
>   * provided with this file.
>   *
>   * These licences may be found online, linked from the end-user license
>   * agreement that is located at http://www.povray.org/povlegal.html
>   *---------------------------------------------------------------------------
>   * This program is based on the popular DKB raytracer version 2.12.
>   * DKBTrace was originally written by David K. Buck.
>   * DKBTrace Ver 2.0-2.12 were written by David K. Buck & Aaron A. Collins.
>   *---------------------------------------------------------------------------
>   * $File: //depot/povray/spec-3.6/source/quadrics.cpp $
>   * $Revision: #1 $
>   * $Change: 5014 $
>   * $DateTime: 2010/06/13 03:51:51 $
>   * $Author: thorsten $
>   * $Log$
>   *****************************************************************************/
> 
> 
> And once again, my simple fix, at least for the SPEC 2017 test case, was to
> simply, rerun the "set small values to 0" check after the "recalculation".
> 
> 
>   808   /* Get quadrics coefficients. */
>   809
>   810   A = Quadric->Square_Terms[X];
>   811   E = Quadric->Square_Terms[Y];
>   812   H = Quadric->Square_Terms[Z];
>   813   B = Quadric->Mixed_Terms[X] / 2.0;
>   814   C = Quadric->Mixed_Terms[Y] / 2.0;
>   815   F = Quadric->Mixed_Terms[Z] / 2.0;
>   816   D = Quadric->Terms[X] / 2.0;
>   817   G = Quadric->Terms[Y] / 2.0;
>   818   I = Quadric->Terms[Z] / 2.0;
>   819   J = Quadric->Constant;
>   820
>   821   /* Set small values to 0. */
>   822
>   823   if (fabs(A) < EPSILON) A = 0.0;
>   824   if (fabs(B) < EPSILON) B = 0.0;
>   825   if (fabs(C) < EPSILON) C = 0.0;
>   826   if (fabs(D) < EPSILON) D = 0.0;
>   827   if (fabs(E) < EPSILON) E = 0.0;
>   828   if (fabs(F) < EPSILON) F = 0.0;
>   829   if (fabs(G) < EPSILON) G = 0.0;
>   830   if (fabs(H) < EPSILON) H = 0.0;
>   831   if (fabs(I) < EPSILON) I = 0.0;
>   832   if (fabs(J) < EPSILON) J = 0.0;
> 
>   <skip some lines>
> 
>   893     /* Recalculate coefficients. */
>   894
>   895     D += A * T1[X];
>   896     G += E * T1[Y];
>   897     I += H * T1[Z];
>   898     J -= T1[X]*(A*T1[X] + 2.0*D) + T1[Y]*(E*T1[Y] + 2.0*G) + T1[Z]*(H*T1[Z]
> + 2.0*I);
> 
>           /* Simple fix to redo the "set small values to 0." after
>              the recalculation. */
> 
>           /* The SPEC 2017 case only needs this reset for J, but I
>              assume it wouldn't hurt to redo for D, G, and I also.
>              Also note that the J recalculation is different with the
>              newer version of POVRAY, but that didn't change the
>              "close to zero, but not actually equal to zero" issue.
> 
>           if (fabs(J) < EPSILON) J = 0.0;
> 
>   899   }
> 
> 
> 
> 
>

[DonF] Re: Set small values to 0. [2046 days 11 hours and 58 minutes ago]

Sun, 30 Aug 2020 05:00:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Awaking this morning though, had a question in my head whether the above
> statement really true? I doubt you are really running v3.7 - or at least
> any official version of v3.7 because your output has the line:

The SPEC 2017 benchmark documentation indicates v3.7, but the SPEC code
itself is still documented as being version 3.6, as indicated from the
below comments from the quadrics.cpp. But it looks like a common issue
between 3.6 and 3.7, unless the issue is resolved elsewhere in the newer
version.

/****************************************************************************
 *               quadrics.cpp
 *
 * This module implements the code for the quadric shape primitive.
 *
 * from Persistence of Vision(tm) Ray Tracer version 3.6.
 * Copyright 1991-2003 Persistence of Vision Team
 * Copyright 2003-2009 Persistence of Vision Raytracer Pty. Ltd.
 *---------------------------------------------------------------------------
 * NOTICE: This source code file is provided so that users may experiment
 * with enhancements to POV-Ray and to port the software to platforms other
 * than those supported by the POV-Ray developers. There are strict rules
 * regarding how you are permitted to use this file. These rules are contained
 * in the distribution and derivative versions licenses which should have been
 * provided with this file.
 *
 * These licences may be found online, linked from the end-user license
 * agreement that is located at http://www.povray.org/povlegal.html
 *---------------------------------------------------------------------------
 * This program is based on the popular DKB raytracer version 2.12.
 * DKBTrace was originally written by David K. Buck.
 * DKBTrace Ver 2.0-2.12 were written by David K. Buck & Aaron A. Collins.
 *---------------------------------------------------------------------------
 * $File: //depot/povray/spec-3.6/source/quadrics.cpp $
 * $Revision: #1 $
 * $Change: 5014 $
 * $DateTime: 2010/06/13 03:51:51 $
 * $Author: thorsten $
 * $Log$
 *****************************************************************************/

And once again, my simple fix, at least for the SPEC 2017 test case, was to
simply, rerun the "set small values to 0" check after the "recalculation".

 808   /* Get quadrics coefficients. */
 809
 810   A = Quadric->Square_Terms[X];
 811   E = Quadric->Square_Terms[Y];
 812   H = Quadric->Square_Terms[Z];
 813   B = Quadric->Mixed_Terms[X] / 2.0;
 814   C = Quadric->Mixed_Terms[Y] / 2.0;
 815   F = Quadric->Mixed_Terms[Z] / 2.0;
 816   D = Quadric->Terms[X] / 2.0;
 817   G = Quadric->Terms[Y] / 2.0;
 818   I = Quadric->Terms[Z] / 2.0;
 819   J = Quadric->Constant;
 820
 821   /* Set small values to 0. */
 822
 823   if (fabs(A) < EPSILON) A = 0.0;
 824   if (fabs(B) < EPSILON) B = 0.0;
 825   if (fabs(C) < EPSILON) C = 0.0;
 826   if (fabs(D) < EPSILON) D = 0.0;
 827   if (fabs(E) < EPSILON) E = 0.0;
 828   if (fabs(F) < EPSILON) F = 0.0;
 829   if (fabs(G) < EPSILON) G = 0.0;
 830   if (fabs(H) < EPSILON) H = 0.0;
 831   if (fabs(I) < EPSILON) I = 0.0;
 832   if (fabs(J) < EPSILON) J = 0.0;

 <skip some lines>

 893     /* Recalculate coefficients. */
 894
 895     D += A * T1[X];
 896     G += E * T1[Y];
 897     I += H * T1[Z];
 898     J -= T1[X]*(A*T1[X] + 2.0*D) + T1[Y]*(E*T1[Y] + 2.0*G) + T1[Z]*(H*T1[Z]
+ 2.0*I);

         /* Simple fix to redo the "set small values to 0." after
            the recalculation. */

         /* The SPEC 2017 case only needs this reset for J, but I
            assume it wouldn't hurt to redo for D, G, and I also.
            Also note that the J recalculation is different with the
            newer version of POVRAY, but that didn't change the
            "close to zero, but not actually equal to zero" issue.

         if (fabs(J) < EPSILON) J = 0.0;

 899   }

[William F Pokorny] Re: Set small values to 0. [2049 days 6 hours and 12 minutes ago]

Thu, 27 Aug 2020 10:45:22 GMT

On 8/25/20 11:17 PM, DonF wrote:
> Description of the SPEC test case:
> 
>     POV-Ray is a free and open source ray-tracing application. The CPU2017
>     version is based on POV-Ray version 3.7.

Yesterday, I quickly read your answer - thank you. On seeing Thorsten's 
post decided not to post myself.

Awaking this morning though, had a question in my head whether the above 
statement really true? I doubt you are really running v3.7 - or at least 
any official version of v3.7 because your output has the line:

Light Buffer                2057730695      1350487574     65.63

and this support was dropped in v3.7 onward.

When thinking about your issue, I was looking at the v3.8 code base and 
those github issues are against v3.7 / v3.8 versions.

FWIW I guess. Thorsten will better know whats going on.

Bill P.

[Thorsten] Re: Set small values to 0. [2050 days 10 hours and 51 minutes ago]

Wed, 26 Aug 2020 06:07:08 GMT

I will see if I can spare some time to take a look at this over the weekend.

Thorsten Froehlich

On 26.08.2020 05:17, DonF wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> DETAILS:
> 
> Description of the SPEC test case:
> 
>     POV-Ray is a free and open source ray-tracing application. The CPU2017
>     version is based on POV-Ray version 3.7.
> 
>     The benchmark renders a 2560 x 2048 pixel image of a chess board, with the
>     pieces placed on the board in the starting position. The rendered scene
>     image is saved as a Targa (.tga) file.
> 
>     This output image is compared with the reference output image using the
>     SPEC utility [1]imagevalidate, which calculates a the structural
>     similarity (SSIM) index between corresponding 8x8 groups of pixels in each
>     image. The SSIM index has a range of -1 (maximal difference) to 1
>     (identical). The benchmark requires that all computed SSIM indices be
>     greater than 0.996 in order for the run to be considered successful.
> 
>     A log of the execution is also generated, but its contents are not used to
>     validate correction operation of the benchmark.
> 
>     POV-Ray (which became 511.povray_r) was contributed to CPU2017 by one of
>     the developers, Thorsten Froehlich, under the GNU Affero License v3.
> 
> 
> Performance of SPEC2017 REF sized test case:
> 
>    Sample performance difference using Intel compiler on a Skylake system
>    with the spec2017 REF size test case, but most compilers on most platforms,
>    including x86 or ARM platforms, can see similar large performance differences
>    with just this one slight numerical difference in J.
> 
>      If J turns out to be zero, or if reset.          218 seconds.
>      Without resetting J to zero when close to zero.  349 seconds. 60% slower.
> 
>    Both output images validated successfully using the SPEC imagevalidate method,
>    but the one output image took much longer to generate.
> 
> 
> Input .ini file used for the SPEC2017 REF sized test case:
> 
> Width=2560
> Height=2048
> All_Console=On
> All_File=SPEC-benchmark.log
> Antialias_Depth=3
> Antialias=On
> Antialias_Threshold=0.3
> Bits_Per_Color=8
> Bounding_Threshold=1
> Bounding=On
> Buffer_Output=Off
> Buffer_Size=0
> Clock=0
> Continue_Trace=Off
> Create_Histogram=Off
> Cyclic_Animation=Off
> Debug_Console=Off
> Display=Off
> Display_Gamma=1.0
> Draw_Vistas=Off
> Fatal_Console=On
> Fatal_Error_Command=
> Fatal_Error_Return=I
> Field_Render=Off
> Final_Clock=1
> Final_Frame=1
> Histogram_Name=
> Histogram_Grid_Size=0.0
> Initial_Clock=0
> Initial_Frame=1
> Include_Header=
> Input_File_Name=SPEC-benchmark-ref.pov
> Jitter_Amount=0.30
> Jitter=Off
> Light_Buffer=On
> Odd_Field=Off
> Output_Alpha=Off
> Output_File_Name=SPEC-benchmark.tga
> Output_File_Type=t
> Palette=3
> Pause_When_Done=Off
> Post_Frame_Command=
> Post_Frame_Return=I
> Post_Scene_Command=
> Post_Scene_Return=I
> Preview_End_Size=1
> Preview_Start_Size=1
> Pre_Frame_Command=
> Pre_Frame_Return=I
> Pre_Scene_command=
> Pre_Scene_Return=I
> Quality=9
> Remove_Bounds=Off
> Render_Console=On
> Sampling_Method=1
> Split_Unions=Off
> Statistic_Console=On
> Subset_End_Frame=1
> Subset_Start_Frame=1
> Test_Abort_Count=0
> Test_Abort=Off
> User_Abort_Command=
> User_Abort_Return=I
> Verbose=Off
> Version=3.5
> Video_Mode=0
> Vista_Buffer=On
> Warning_Console=Off
> 
> 
> Description of input .pov:
> 
>      // Persistence Of Vision raytracer sample file.
>      // POV-Ray scene description for chess board.
>      // By Ville Saari
>      // Copyright (c) 1991 Ferry Island Pixelboys
>      //
>      // This scene has 430 primitives in objects and 41 in bounding shapes and
>      // it takes over 40 hours to render by standard amiga.
>      //
>      // If you do some nice modifications or additions to this file, please send
>      // me a copy. My Internet address is:  vsa### [at] niksulahutfi
>      //
>      // -w320 -h240
>      // -w800 -h600 +a0.3
> 
>      // Note : CHESS2.POV was created from Ville Saari's chess.pov
>      // -- Dan Farmer 1996
>      //  - Cchanged textures
>      //  - Added camera blur and changed focal length
>      //  - Use sky sphere
>      //  - Modularized the code
>      //  - Added felt pads to bottom of pieces
> 
>      // remaining manual bounding commented out by Bob Hughes, August 31, 2001
> 
> 
> Execution Trace:
> 
>    With my own little debug trace through the Compute_Quadric_BBox() routine of
>    file quadrics.cpp using the SPEC test case, I see 19 calls to the
>    Compute_Quadric_BBox() routine.
> 
>    All calls to Compute_Quadric_BBox() execute one of the many
>    "Check for xxxxxxx (?-axis)" code blocks, EXCEPT the one case where
>    "J is recalculated, ends up being close to zero, but not quite zero,
>    and is not reset". In this one case, none of the "Check ..." code blocks are
>    executed, the "Add translation" and the "Beware of bounding boxes to large"
>    are executed, and large values for BBox.Lengths the BBox.Lower_Left values
>    are used.
> 
> 
>    Executed code when J is "recalculated" and ends up being exactly equal to
>    0.0 (or is reset to zero if close) for the 1 of 19 cases that differed:
> 
>      J was recalculated to J=4.440892e-16,
>      and then reset to 0.0 with modified code I added.
> 
>        Check for cone (y-axis).
>        Add translation.
>        Quadric->BBox.Lengths 0 to 2:     4.333333 3.500000  4.333333
>        Quadric->BBox.Lower_Left 0 to 2: -2.166667 8.000000 -2.166667
> 
> 
>    Executed code when J is "recalculated" and ends up NOT quite being exactly
>    equal to 0.0:
> 
>        Add translation.
>        Beware of bounding boxes to large.
>        Quadric->BBox.Lengths 0 to 2:     20000000000.000000  20000000000.000000
> 20000000000.000000
>        Quadric->BBox.Lower_Left 0 to 2: -10000000000.000000 -10000000000.000000
> -10000000000.000000
> 
>    For the faster executing run, note that the "Beware of bounding boxes to
>    large" code block is still executed for 8 of the 19 calls to
>    Compute_Quadric_BBox(), and even when "Beware of bounding boxes to large"
>    is NOT called, the large BBox values may be still be set or inherited.
>    For this faster test case, 12 of the 19 calls to
>    Compute_Quadric_BBox() ended up with large BBox values, so having the
>    large BBox values is not unusual, but for the one call where J was not
>    reset when perhaps it could/should have been reset, the large BBox values
>    were one of the differences encountered between the slower and faster
>    runs.
> 
> 
> Portion of log file results (not used for SPEC verification) for the
> fast and slow execution.
> 
>    Fast execution with recalculated J reset to zero when it is close to zero:
>    218 seconds.
> 
>      Image Resolution 2560 x 2048
>      ----------------------------------------------------------------------------
>      Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
>      Rays:          114705211   Saved:           1162288   Max Level: 5/5
>      ----------------------------------------------------------------------------
>      Ray->Shape Intersection          Tests       Succeeded  Percentage
>      ----------------------------------------------------------------------------
>      Box                           16019108        16019107    100.00
>      Cone/Cylinder                 12818313         3292990     25.69
>      CSG Intersection            1100588845       111370367     10.12
>      CSG Union                     88374684        76631294     86.71
>      Plane                       4514922317      2468835793     54.68
>      Quadric                      330552192       175746735     53.17
>      Sphere                       289188952        70116199     24.25
>      Bounding Box                2485773879       745702120     30.00
>      Light Buffer                1823322702      1064180254     58.36
>      ----------------------------------------------------------------------------
> 
> 
>    Slow execution with recalculated J NOT reset to zero when it was close
>    to zero: 349 seconds.
> 
>         Note the large increase in "Tests" for many of the
>         "Ray->Shape Intersestion" values, such as CSG Intersection, Plane,
>         Quadric, and Sphere, (flagged with **) which presumably
>         results in the large increase in execution time.
> 
>      Image Resolution 2560 x 2048
>      ----------------------------------------------------------------------------
>      Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
>      Rays:          114705211   Saved:           1162288   Max Level: 5/5
>      ----------------------------------------------------------------------------
>      Ray->Shape Intersection          Tests       Succeeded  Percentage
>      ----------------------------------------------------------------------------
>      Box                           16019108        16019107    100.00
>      Cone/Cylinder                 12818313         3292990     25.69
>      CSG Intersection            2573044515**     113104449      4.40
>      CSG Union                     88374684        76631294     86.71
>      Plane                       5987377987**    3804982796     63.55
>      Quadric                     1066780027**     285487345     26.76
>      Sphere                      9123922972**      73475346      0.81
>      Bounding Box                2368729644       732816314     30.94
>      Light Buffer                2057730695      1350487574     65.63
>      ----------------------------------------------------------------------------
> 
> 
> 
>> My quick take is those initial EPSILONs (1e-10 in POV-Ray) should be
>> more like what I'm using in my personal povr branch (gkDBL_epsilon at
>> ~ 4.4e-16)
> 
> Based on my observations, 4.4e-16 might be a little too restrictive to catch
> many of the obvious "close to zero values". An EPSILON of 1e-10 may,
> or may not, be too lax, but I think 4.4e-16 would be too restrictive.
> The recalculated values of J that were not close to zero for this case,
> and hence didn't need to be reset were either -1.0, or already 0.0.
> 
> 
>

[DonF] Re: Set small values to 0. [2050 days 13 hours and 38 minutes ago]

Wed, 26 Aug 2020 03:20:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

DETAILS:

Description of the SPEC test case:

   POV-Ray is a free and open source ray-tracing application. The CPU2017
   version is based on POV-Ray version 3.7.

   The benchmark renders a 2560 x 2048 pixel image of a chess board, with the
   pieces placed on the board in the starting position. The rendered scene
   image is saved as a Targa (.tga) file.

   This output image is compared with the reference output image using the
   SPEC utility [1]imagevalidate, which calculates a the structural
   similarity (SSIM) index between corresponding 8x8 groups of pixels in each
   image. The SSIM index has a range of -1 (maximal difference) to 1
   (identical). The benchmark requires that all computed SSIM indices be
   greater than 0.996 in order for the run to be considered successful.

   A log of the execution is also generated, but its contents are not used to
   validate correction operation of the benchmark.

   POV-Ray (which became 511.povray_r) was contributed to CPU2017 by one of
   the developers, Thorsten Froehlich, under the GNU Affero License v3.

Performance of SPEC2017 REF sized test case:

  Sample performance difference using Intel compiler on a Skylake system
  with the spec2017 REF size test case, but most compilers on most platforms,
  including x86 or ARM platforms, can see similar large performance differences
  with just this one slight numerical difference in J.

    If J turns out to be zero, or if reset.          218 seconds.
    Without resetting J to zero when close to zero.  349 seconds. 60% slower.

  Both output images validated successfully using the SPEC imagevalidate method,
  but the one output image took much longer to generate.

Input .ini file used for the SPEC2017 REF sized test case:

Width=2560
Height=2048
All_Console=On
All_File=SPEC-benchmark.log
Antialias_Depth=3
Antialias=On
Antialias_Threshold=0.3
Bits_Per_Color=8
Bounding_Threshold=1
Bounding=On
Buffer_Output=Off
Buffer_Size=0
Clock=0
Continue_Trace=Off
Create_Histogram=Off
Cyclic_Animation=Off
Debug_Console=Off
Display=Off
Display_Gamma=1.0
Draw_Vistas=Off
Fatal_Console=On
Fatal_Error_Command=
Fatal_Error_Return=I
Field_Render=Off
Final_Clock=1
Final_Frame=1
Histogram_Name=
Histogram_Grid_Size=0.0
Initial_Clock=0
Initial_Frame=1
Include_Header=
Input_File_Name=SPEC-benchmark-ref.pov
Jitter_Amount=0.30
Jitter=Off
Light_Buffer=On
Odd_Field=Off
Output_Alpha=Off
Output_File_Name=SPEC-benchmark.tga
Output_File_Type=t
Palette=3
Pause_When_Done=Off
Post_Frame_Command=
Post_Frame_Return=I
Post_Scene_Command=
Post_Scene_Return=I
Preview_End_Size=1
Preview_Start_Size=1
Pre_Frame_Command=
Pre_Frame_Return=I
Pre_Scene_command=
Pre_Scene_Return=I
Quality=9
Remove_Bounds=Off
Render_Console=On
Sampling_Method=1
Split_Unions=Off
Statistic_Console=On
Subset_End_Frame=1
Subset_Start_Frame=1
Test_Abort_Count=0
Test_Abort=Off
User_Abort_Command=
User_Abort_Return=I
Verbose=Off
Version=3.5
Video_Mode=0
Vista_Buffer=On
Warning_Console=Off

Description of input .pov:

    // Persistence Of Vision raytracer sample file.
    // POV-Ray scene description for chess board.
    // By Ville Saari
    // Copyright (c) 1991 Ferry Island Pixelboys
    //
    // This scene has 430 primitives in objects and 41 in bounding shapes and
    // it takes over 40 hours to render by standard amiga.
    //
    // If you do some nice modifications or additions to this file, please send
    // me a copy. My Internet address is:  vsa### [at] niksulahutfi
    //
    // -w320 -h240
    // -w800 -h600 +a0.3

    // Note : CHESS2.POV was created from Ville Saari's chess.pov
    // -- Dan Farmer 1996
    //  - Cchanged textures
    //  - Added camera blur and changed focal length
    //  - Use sky sphere
    //  - Modularized the code
    //  - Added felt pads to bottom of pieces

    // remaining manual bounding commented out by Bob Hughes, August 31, 2001

Execution Trace:

  With my own little debug trace through the Compute_Quadric_BBox() routine of
  file quadrics.cpp using the SPEC test case, I see 19 calls to the
  Compute_Quadric_BBox() routine.

  All calls to Compute_Quadric_BBox() execute one of the many
  "Check for xxxxxxx (?-axis)" code blocks, EXCEPT the one case where
  "J is recalculated, ends up being close to zero, but not quite zero,
  and is not reset". In this one case, none of the "Check ..." code blocks are
  executed, the "Add translation" and the "Beware of bounding boxes to large"
  are executed, and large values for BBox.Lengths the BBox.Lower_Left values
  are used.

  Executed code when J is "recalculated" and ends up being exactly equal to
  0.0 (or is reset to zero if close) for the 1 of 19 cases that differed:

    J was recalculated to J=4.440892e-16,
    and then reset to 0.0 with modified code I added.

      Check for cone (y-axis).
      Add translation.
      Quadric->BBox.Lengths 0 to 2:     4.333333 3.500000  4.333333
      Quadric->BBox.Lower_Left 0 to 2: -2.166667 8.000000 -2.166667

  Executed code when J is "recalculated" and ends up NOT quite being exactly
  equal to 0.0:

      Add translation.
      Beware of bounding boxes to large.
      Quadric->BBox.Lengths 0 to 2:     20000000000.000000  20000000000.000000
20000000000.000000
      Quadric->BBox.Lower_Left 0 to 2: -10000000000.000000 -10000000000.000000
-10000000000.000000

  For the faster executing run, note that the "Beware of bounding boxes to
  large" code block is still executed for 8 of the 19 calls to
  Compute_Quadric_BBox(), and even when "Beware of bounding boxes to large"
  is NOT called, the large BBox values may be still be set or inherited.
  For this faster test case, 12 of the 19 calls to
  Compute_Quadric_BBox() ended up with large BBox values, so having the
  large BBox values is not unusual, but for the one call where J was not
  reset when perhaps it could/should have been reset, the large BBox values
  were one of the differences encountered between the slower and faster
  runs.

Portion of log file results (not used for SPEC verification) for the
fast and slow execution.

  Fast execution with recalculated J reset to zero when it is close to zero:
  218 seconds.

    Image Resolution 2560 x 2048
    ----------------------------------------------------------------------------
    Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
    Rays:          114705211   Saved:           1162288   Max Level: 5/5
    ----------------------------------------------------------------------------
    Ray->Shape Intersection          Tests       Succeeded  Percentage
    ----------------------------------------------------------------------------
    Box                           16019108        16019107    100.00
    Cone/Cylinder                 12818313         3292990     25.69
    CSG Intersection            1100588845       111370367     10.12
    CSG Union                     88374684        76631294     86.71
    Plane                       4514922317      2468835793     54.68
    Quadric                      330552192       175746735     53.17
    Sphere                       289188952        70116199     24.25
    Bounding Box                2485773879       745702120     30.00
    Light Buffer                1823322702      1064180254     58.36
    ----------------------------------------------------------------------------

  Slow execution with recalculated J NOT reset to zero when it was close
  to zero: 349 seconds.

       Note the large increase in "Tests" for many of the
       "Ray->Shape Intersestion" values, such as CSG Intersection, Plane,
       Quadric, and Sphere, (flagged with **) which presumably
       results in the large increase in execution time.

    Image Resolution 2560 x 2048
    ----------------------------------------------------------------------------
    Pixels:          5242880   Samples:        56705552   Smpls/Pxl: 10.82
    Rays:          114705211   Saved:           1162288   Max Level: 5/5
    ----------------------------------------------------------------------------
    Ray->Shape Intersection          Tests       Succeeded  Percentage
    ----------------------------------------------------------------------------
    Box                           16019108        16019107    100.00
    Cone/Cylinder                 12818313         3292990     25.69
    CSG Intersection            2573044515**     113104449      4.40
    CSG Union                     88374684        76631294     86.71
    Plane                       5987377987**    3804982796     63.55
    Quadric                     1066780027**     285487345     26.76
    Sphere                      9123922972**      73475346      0.81
    Bounding Box                2368729644       732816314     30.94
    Light Buffer                2057730695      1350487574     65.63
    ----------------------------------------------------------------------------

> My quick take is those initial EPSILONs (1e-10 in POV-Ray) should be
> more like what I'm using in my personal povr branch (gkDBL_epsilon at
> ~ 4.4e-16)

Based on my observations, 4.4e-16 might be a little too restrictive to catch
many of the obvious "close to zero values". An EPSILON of 1e-10 may,
or may not, be too lax, but I think 4.4e-16 would be too restrictive.
The recalculated values of J that were not close to zero for this case,
and hence didn't need to be reset were either -1.0, or already 0.0.

[William F Pokorny] Re: Set small values to 0. [2051 days 6 hours and 2 minutes ago]

Tue, 25 Aug 2020 10:56:12 GMT

On 8/24/20 6:55 PM, DonF wrote:
> POV-Ray 3.7 is part of the SPEC 2017 suite of benchmarks. While running POVRAY
> from SPEC, I see some very significant performance differences that are
> triggered by some very slight numerical differences. Apparently, the very slight
> numerical differences cause different code paths to be taken resulting in the
> very significant performance differences in subsequently executed routines.
> 
> The 3.7 version file involved is quadrics.cpp, and the routine involved is
> Compute_Quadric_BBox().
...

I agree code is not optimal. As to what to do...

Is the SPEC 2017 suite running the inbuilt benchmark(1) or is this some 
particular scene file? If the latter, could you provide that file or a 
link to it as well as it's associated .ini file or command line flag set?

(1) - IIRC there is no quadric in the benchmark, but...

With the significant performance differences, could you provide some 
detail? Numbers, running environments, ...

My quick take is those initial EPSILONs (1e-10 in POV-Ray) should be 
more like what I'm using in my personal povr branch (gkDBL_epsilon at ~ 
4.4e-16) which would make the initial zeroing less aggressive and so 
re-zeroing(1) of the recalculated values would less likely result in 
performance improvements, but likely in more stable performance results.

This sort of change should be safe where there is some chance, with the 
current EPSILON value, the re-zeroing of D, G, I or J would not be for 
particular shapes/surfaces.

---
Asides:

-
The quadric shape is not all that frequently used these days by POV-Ray 
users. Parabolic shapes are probably the most common. Fixing things 
related to it have gotten lower priority over time.

-
There are several github issues tangled in the quadric bounding.

Broken quadric bounding in CSG intersection and difference. #315
https://github.com/POV-Ray/povray/issues/315

and

Investigate and review use of CRITICAL_LENGTH in code. #379
https://github.com/POV-Ray/povray/issues/379

come to mind, but there are others. I suspect part of the issue with 
quadric bounding is the shapes often have an infinite aspect to them.

-
I wonder if the automatic bounding not the best idea for quadratics due 
numerical issues. If a user knows she specified a parabola, she likely 
knows what bounding of use to for her application outright. If not 
precisely, then she knows the parabolic bounding calculation is the 
correct one to use and could call code for to calculate it.

Given the differences are large I suspect what is happening is the j not 
being zero essentially bypasses the appropriate automatic bounding 
calculation(2) and we get the initial huge bounding box - and so ray - 
surface root finding gets run all the time(2a).

(2) - This touches on another possible change. Namely, being smarter 
about the j tests in each of those bounding conditionals. We would need 
to really think about what small j values matter for each type of 
shape/surface and then use better values.

(2a) - If the bounding off options completely worked in v3.7 and v3.8 as 
they did v3.6, for specmark testing you could just turn off all the 
bounding so long as the scene is not too complicated. Moot point today 
as one cannot 'completely' turn off bounding in v3.7/v3.8; the bbox 
closest to the shape is always sometimes in play and that's the bbox 
being calculated here.

---
Given the tangle of issues above, it might make the most sense for 
specmark testing to change the scene(s) involved to avoid the quadratic 
shape. Or to implement and always use user bounding; In v3.7 & v3.8 the 
user bounding is forced off by default and automatic bounding is used 
instead.

Anyway.

Bill P.

[Bald Eagle] Re: Set small values to 0. [2051 days 17 hours and 13 minutes ago]

Mon, 24 Aug 2020 23:45:00 GMT

"DonF" <nomail@nomail> wrote:

> However, after the above adjustments of some small values to 0.0 are completed,
> a few of the values are recalculated, which once again results in some small
> values that are not equal to zeo, such as J for the SPEC test case.

Yuk.

Nice catch!  I'm sure it must have taken quite a bit of digging to uncover the
root cause of this.   It sounds a lot like the triangle normal bug that surfaced
a while back.
http://news.povray.org/povray.binaries.scene-files/message/%3C57b5e71b%241%40news.povray.org%3E/#%3C57b5e71b%241%40news
.povray.org%3E

The bigger it gets, the more complicated it gets to debug...  ;)

[DonF] Set small values to 0. [2051 days 17 hours and 58 minutes ago]

Mon, 24 Aug 2020 23:00:01 GMT

POV-Ray 3.7 is part of the SPEC 2017 suite of benchmarks. While running POVRAY
from SPEC, I see some very significant performance differences that are
triggered by some very slight numerical differences. Apparently, the very slight
numerical differences cause different code paths to be taken resulting in the
very significant performance differences in subsequently executed routines.

The 3.7 version file involved is quadrics.cpp, and the routine involved is
Compute_Quadric_BBox().

In Compute_Quadric_BBox(), some values are setup that control how much work is
ultimately done elsewhere in the program. In this routine, some setup work is
performed based on all sort of floating point compares to 0.0: > 0.0, < 0.0, ==
0.0, and != 0.0. With these critical comparisons to 0.0, slight numerical
differences can result in a different setup, so it is very important that if a
value is intended to be 0.0, that it is actually 0.0.

And obtaining actual 0.0 values is partially obtained by setting values that are
close to zero to actually be 0.0, such as, the below POVRAY code.

  /* Set small values to 0. */

  if (fabs(A) < EPSILON) A = 0.0;
  if (fabs(B) < EPSILON) B = 0.0;
  if (fabs(C) < EPSILON) C = 0.0;
  if (fabs(D) < EPSILON) D = 0.0;
  if (fabs(E) < EPSILON) E = 0.0;
  if (fabs(F) < EPSILON) F = 0.0;
  if (fabs(G) < EPSILON) G = 0.0;
  if (fabs(H) < EPSILON) H = 0.0;
  if (fabs(I) < EPSILON) I = 0.0;
  if (fabs(J) < EPSILON) J = 0.0;

However, after the above adjustments of some small values to 0.0 are completed,
a few of the values are recalculated, which once again results in some small
values that are not equal to zeo, such as J for the SPEC test case. Certain
compilers versions or compiler options may result in an exact value of
0.000000e+00, but with most compiler versions and options, due to the limited
precision of floating point operations, the J values end up being something
close to zero, like 8.881784e-16, but not actually zero, resulting in the
different setup to be performance and much poorer performance.

    /* Recalculate coefficients. */

    D += A * T1[X];
    G += E * T1[Y];
    I += H * T1[Z];
    J -= T1[X]*(A*T1[X] + 2.0*D) + T1[Y]*(E*T1[Y] + 2.0*G) + T1[Z]*(H*T1[Z] +
2.0*I);

If the J value is simply re-adjusted back to 0., as was done earlier, then much
better performance is obtained without changing the correctness of the generated
..tga files.

As mentioned above, SPEC is based off of POV-Ray 3.7 and although file names
have changed and updates have occurred in 3.8, the same basic issue is still
appears to be present in 3.8.

So my question is:

Should the "set small values to 0." adjustments be re-made, primarily for "J",
 so that consistent comparisons can be make to 0.0, or was it intentional
not to make any readjustments to "set small values to 0." after the "recalculate
coefficients" was performed?

[Thomas Debe] Re: Interested in CMake support (build system, I... [2125 days 2 hours and 11 minutes ago]

Fri, 12 Jun 2020 14:46:26 GMT

Am 11.06.20 um 16:54 schrieb Mr:
> "LanuHum" <Lan### [at] yandexru> wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 22.10.2016 um 12:42 schrieb LanuHum:
>>>> For example, the structure is different from the master and hgpovray.
>>>> Now I understand why stupid written configuration files gnumake.
>>>> CMakeListsGenerator.py
>>>
>>> So instead of an Automake script we'd get a Python script?
>>>
>>> I'm not sure if this is really a win -- most notably since Automake does
>>> a lot more than just determine what files to compile and what libraries
>>> to link, such as detecting whether particular semi-standard include
>>> files, data types or functions are available (defining all those
>>> HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
>>> code).
>>
>>
>> I do not reinvent the wheel. I just do not know Automake, but need to build the
>> program. I do not know where I have to write the changes to be included in your
>> project my files. I found a solution to the primitive, but it works.
>>
>> My posts on this thread are just an idea.
>> Someone might want to develop it.
>> The source code of the blender always had several options for building:
>> cmake, make and scons.
>> Scons uses python.
>>
>>
>> :)
> 
> 
> The first CMake repository provided by ideasman42 has been removed :-( I asked
> if he had kept an archive and no he didn't ... would any compulsive downloader
> have kept a version somwhere? I tried the Internet Archive to no success as
> well.
> 
> 
> 
> 
Hello !
Look at
<5ee393f7$1@news.povray.org>

povray.binaries.programming

regards
Thomas

[Mr] Re: Interested in CMake support (build system, I... [2126 days 2 hours and 3 minutes ago]

Thu, 11 Jun 2020 14:55:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 22.10.2016 um 12:42 schrieb LanuHum:
> > > For example, the structure is different from the master and hgpovray.
> > > Now I understand why stupid written configuration files gnumake.
> > > CMakeListsGenerator.py
> >
> > So instead of an Automake script we'd get a Python script?
> >
> > I'm not sure if this is really a win -- most notably since Automake does
> > a lot more than just determine what files to compile and what libraries
> > to link, such as detecting whether particular semi-standard include
> > files, data types or functions are available (defining all those
> > HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
> > code).
>
>
> I do not reinvent the wheel. I just do not know Automake, but need to build the
> program. I do not know where I have to write the changes to be included in your
> project my files. I found a solution to the primitive, but it works.
>
> My posts on this thread are just an idea.
> Someone might want to develop it.
> The source code of the blender always had several options for building:
> cmake, make and scons.
> Scons uses python.
>
>
> :)


The first CMake repository provided by ideasman42 has been removed :-( I asked
if he had kept an archive and no he didn't ... would any compulsive downloader
have kept a version somwhere? I tried the Internet Archive to no success as
well.

[Tor Olav Kristensen] Re: "linked" value functions [2174 days 21 hours and 48 minutes ago]

Thu, 23 Apr 2020 19:10:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I've come across this a few times, and I'm not sure if this is a "usual"
> operation or a formal function/macro in certain languages.
>
> I want to compare two values, but I want to then utilize a third, linked value.
>
> So in the current situation, I'm looking at the dimensions of vectors during a
> rotation, and a typical operation is to do something like:
> #local MaxX = max(TestValue, MaxX);
>
> But I don't want to keep track of the magnitude of maximum vector - I want to
> keep track of the ANGLE of rotation at which that maximum occurs.
>
> Obviously I can concoct some sort of macro to handle this, but it just seemed to
> me that this must be a somewhat common task, to the point where such a function
> might exist and have a name.

Hi Bill

If the value for each component is a function of an angle - and you know this
function, then it may be that you can find the extreme points analytically.

If you don't know this function, then here's some terms to search for and some
relevant links.

golden section search
Fibonacci search
Newton Raphson optimization
optimization in one dimension
numerical optimization
numerical analysis extremum (or extremes)

https://mathforcollege.com/nm/mws/gen/09opt/mws_gen_opt_txt_newopt.pdf
http://mathforcollege.com/nm/mws/gen/03nle/mws_gen_nle_txt_newton.pdf
http://www.lendek.net/teaching/opt_en/numerical%20optimization.pdf
https://relate.cs.illinois.edu/course/cs357-f15/file-version/03473f64afb954c74c02e8988f518de3eddf49a4/media/cs357-slide
s-newton2.pdf
https://en.wikipedia.org/wiki/Maxima_and_minima
https://en.wikipedia.org/wiki/Golden-section_search

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] "linked" value functions [2174 days 22 hours and 53 minutes ago]

Thu, 23 Apr 2020 18:05:01 GMT

So, I've come across this a few times, and I'm not sure if this is a "usual"
operation or a formal function/macro in certain languages.

I want to compare two values, but I want to then utilize a third, linked value.

So in the current situation, I'm looking at the dimensions of vectors during a
rotation, and a typical operation is to do something like:
#local MaxX = max(TestValue, MaxX);

But I don't want to keep track of the magnitude of maximum vector - I want to
keep track of the ANGLE of rotation at which that maximum occurs.

Obviously I can concoct some sort of macro to handle this, but it just seemed to
me that this must be a somewhat common task, to the point where such a function
might exist and have a name.

[jr] Re: povmodeler [2266 days 10 hours and 53 minutes ago]

Thu, 23 Jan 2020 06:05:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Maybe this might be a better way handle all the different OS's?
>
> ...

already in wide-spread use is:
<https://en.wikipedia.org/wiki/LXC>

(a bit more general, and not "initimately linked" to Ubuntu owners)


regards, jr.

[Bald Eagle] Re: povmodeler [2266 days 19 hours and 38 minutes ago]

Wed, 22 Jan 2020 21:20:00 GMT

Maybe this might be a better way handle all the different OS's?

https://itsfoss.com/install-snap-linux/

[simbad] Re: povmodeler [2297 days 4 hours and 13 minutes ago]

Mon, 23 Dec 2019 12:45:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "simbad" <Han### [at] gmxde> wrote:
> > > ...
> > I dont think I will really "release" any version with the old code as it is hard
> > to maintain and is in many ways complicated.
> > But on the other hand I want to keep on to support the old users as good as
> > possible. I already started a rewrite of the GUI but this will take some time.
>
> something to look forward to.  :-)
>
> > So I split my time between support for the old code and to rewrite the GUI.
> >
> > But the build environment and packaging will be needed in both development
> > pathes.
> >
> > For handling of bugs I think it would be best to use the github issue tracker.
>
> ok.
>
> > This would help to establish something near to release managment.
>
> yes, be(com)ing the package maintainer/developer for a software with an existing
> user base is a pretty big hat to wear, I think.  wishing you good fortune.
>
>
> regards, jr.

So ....

found the segfault bug. Fixed some other things from making it run on slackware
and created all packages anew. Because of the work done it gives a new
version-number (only the patch-level).

https://www.simulated-universe.de/povmodeler-1.1.5-debian-10.deb
https://www.simulated-universe.de/povmodeler-1.1.5-linuxmint-18.3.deb
https://www.simulated-universe.de/povmodeler-1.1.5-linuxmint-19.1.deb
https://www.simulated-universe.de/povmodeler-1.1.5-linuxmint-19.2.deb
https://www.simulated-universe.de/povmodeler-1.1.5-opensuse-leap-15.1.rpm
https://www.simulated-universe.de/povmodeler-1.1.5-x86_64-14.1.tgz
https://www.simulated-universe.de/povmodeler-1.1.5-x86_64-14.2.tgz

The slackware packages are the two last with no distro name in them.
Just try it and please report bugs on github. Help can be obtained here.
Questions answered as well.

But I hope I can spend more time on the rewrite.

[jr] Re: povmodeler [2297 days 20 hours and 38 minutes ago]

Sun, 22 Dec 2019 20:20:11 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> > ...
> I dont think I will really "release" any version with the old code as it is hard
> to maintain and is in many ways complicated.
> But on the other hand I want to keep on to support the old users as good as
> possible. I already started a rewrite of the GUI but this will take some time.

something to look forward to.  :-)

> So I split my time between support for the old code and to rewrite the GUI.
>
> But the build environment and packaging will be needed in both development
> pathes.
>
> For handling of bugs I think it would be best to use the github issue tracker.

ok.

> This would help to establish something near to release managment.

yes, be(com)ing the package maintainer/developer for a software with an existing
user base is a pretty big hat to wear, I think.  wishing you good fortune.


regards, jr.

[simbad] Re: povmodeler [2298 days and 3 minutes ago]

Sun, 22 Dec 2019 16:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "simbad" <Han### [at] gmxde> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > "simbad" <Han### [at] gmxde> wrote:
> > > > Hi ho,
> > > > there are two packages available.
> > > > ...
> >
> > git clone https://github.com/tribad/povmodeler.git
> > cd povmodeler
> > git checkout slackware14.x
> > cmake .
> > make
> > make install
>
> > ...
> > Accessing the repo has the advantage that you will stay up to date to any
> > upcoming changes. That would not possible with a source package as it only
> > contains "released" source code.
>
> sure.  I simply assumed that "available packages" means released, and are based
> on "released" code bases  (must be my age ;-)).  thanks though.
>
>
> regards, jr.

I dont think I will really "release" any version with the old code as it is hard
to maintain and is in many ways complicated.
But on the other hand I want to keep on to support the old users as good as
possible. I already started a rewrite of the GUI but this will take some time.
So I split my time between support for the old code and to rewrite the GUI.

But the build environment and packaging will be needed in both development
pathes.

For handling of bugs I think it would be best to use the github issue tracker.
This would help to establish something near to release managment.

[jr] Re: povmodeler [2298 days and 38 minutes ago]

Sun, 22 Dec 2019 16:20:01 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "simbad" <Han### [at] gmxde> wrote:
> > > Hi ho,
> > > there are two packages available.
> > > ...
>
> git clone https://github.com/tribad/povmodeler.git
> cd povmodeler
> git checkout slackware14.x
> cmake .
> make
> make install

> ...
> Accessing the repo has the advantage that you will stay up to date to any
> upcoming changes. That would not possible with a source package as it only
> contains "released" source code.

sure.  I simply assumed that "available packages" means released, and are based
on "released" code bases  (must be my age ;-)).  thanks though.


regards, jr.

[simbad] Re: povmodeler [2298 days 1 hour and 3 minutes ago]

Sun, 22 Dec 2019 15:55:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "simbad" <Han### [at] gmxde> wrote:
> > Hi ho,
> > there are two packages available.
> >
> >  * https://www.simulated-universe.de/povmodeler-1.1.4-x86_64-1hjl.tgz
> >  * https://www.simulated-universe.de/povmodeler-1.1.4-x86_64-2hjl.tgz
> >
> > for slackware-14.1 and slackware-14.2
> >
> > I experienced segfaults on first start. I could not find the cause for now.
> > While it has vanished with the next start it has been hard to identify.
> >
> > While checking a coredump I found an iterator through the action list failed.
> > But the debugging on slackware is hard, as the X11 in a vm runs without any
> > accelleration support. Everything is very slow.
> >
> > So look out for those crashes. Maybe I got some more ideas about the situation
> > that will cause this.
> >
> > I did not created any slackbuild-script but added the slack-desc file to the
> > repo. As it should be easy to be build on a slackware distro now I think I will
> > not deliver the slack-build script.
>
> ah, thanks.  no idea whether it will be "easy to build" since all you provide is
> a binary (system) install.  (I was minded to try the software, but would want to
> build and install it to "fit in")  cheers, anyway.
>
>
> regards, jr.

git clone https://github.com/tribad/povmodeler.git
cd povmodeler
git checkout slackware14.x
cmake .
make
make install

A build script will not do anything different. So if you have anything different
than the standard slackware 14 software installed, even the slack-build may
fail.
So doing it the way I described above should be the way if you want more control
on the build process.

The packages I produced are created on fresh installed vms. So they should work
out if the box.

Accessing the repo has the advantage that you will stay up to date to any
upcoming changes. That would not possible with a source package as it only
contains "released" source code.

[jr] Re: povmodeler [2298 days 1 hour and 48 minutes ago]

Sun, 22 Dec 2019 15:10:00 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> Hi ho,
> there are two packages available.
>
>  * https://www.simulated-universe.de/povmodeler-1.1.4-x86_64-1hjl.tgz
>  * https://www.simulated-universe.de/povmodeler-1.1.4-x86_64-2hjl.tgz
>
> for slackware-14.1 and slackware-14.2
>
> I experienced segfaults on first start. I could not find the cause for now.
> While it has vanished with the next start it has been hard to identify.
>
> While checking a coredump I found an iterator through the action list failed.
> But the debugging on slackware is hard, as the X11 in a vm runs without any
> accelleration support. Everything is very slow.
>
> So look out for those crashes. Maybe I got some more ideas about the situation
> that will cause this.
>
> I did not created any slackbuild-script but added the slack-desc file to the
> repo. As it should be easy to be build on a slackware distro now I think I will
> not deliver the slack-build script.

ah, thanks.  no idea whether it will be "easy to build" since all you provide is
a binary (system) install.  (I was minded to try the software, but would want to
build and install it to "fit in")  cheers, anyway.


regards, jr.

[simbad] Re: povmodeler [2298 days 2 hours and 28 minutes ago]

Sun, 22 Dec 2019 14:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "simbad" <Han### [at] gmxde> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > thanks.  keep "us" in the loop, please.
> >
> > Ok.
> > I do have a version that seems to run on slackware 14.1 and 14.2
> > As I am not very familiar with the functionalities of povmodeler and the qt
> > library tweaks it may still have bugs.
> >
> > But it looks promising as it has been build against the distros qt libs
> > versions. So Qt4.x
> >
> > Next would be to pack that and make it available. But this comes the next days.
> > For now I check whether the other packages still build and work.
>
> have a look at: <https://slackbuilds.org/>
> that is sort of the standard.
>
> if you want to discuss stuff, feel free to email direct.
>
>
> regards, jr.
Hi ho,
there are two packages available.

 * https://www.simulated-universe.de/povmodeler-1.1.4-x86_64-1hjl.tgz
 * https://www.simulated-universe.de/povmodeler-1.1.4-x86_64-2hjl.tgz

for slackware-14.1 and slackware-14.2

I experienced segfaults on first start. I could not find the cause for now.
While it has vanished with the next start it has been hard to identify.

While checking a coredump I found an iterator through the action list failed.
But the debugging on slackware is hard, as the X11 in a vm runs without any
accelleration support. Everything is very slow.

So look out for those crashes. Maybe I got some more ideas about the situation
that will cause this.

I did not created any slackbuild-script but added the slack-desc file to the
repo. As it should be easy to be build on a slackware distro now I think I will
not deliver the slack-build script.

[jr] Re: povmodeler [2298 days 23 hours and 43 minutes ago]

Sat, 21 Dec 2019 17:15:01 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > thanks.  keep "us" in the loop, please.
>
> Ok.
> I do have a version that seems to run on slackware 14.1 and 14.2
> As I am not very familiar with the functionalities of povmodeler and the qt
> library tweaks it may still have bugs.
>
> But it looks promising as it has been build against the distros qt libs
> versions. So Qt4.x
>
> Next would be to pack that and make it available. But this comes the next days.
> For now I check whether the other packages still build and work.

have a look at: <https://slackbuilds.org/>
that is sort of the standard.

if you want to discuss stuff, feel free to email direct.


regards, jr.

[simbad] Re: povmodeler [2299 days 4 hours and 8 minutes ago]

Sat, 21 Dec 2019 12:50:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "simbad" <Han### [at] gmxde> wrote:
> > I worked on the slackware-14.x support and got an executable. But its not good
> > enough to let it out into the wild.
>
> :-)
>
> > But it builds with Qt4 and even the OpenGL things seems to work. But docking of
> > the widgets and some file-loading things are not ready.
>
> thanks.  keep "us" in the loop, please.
>
>
> regards, jr.

Ok.
I do have a version that seems to run on slackware 14.1 and 14.2
As I am not very familiar with the functionalities of povmodeler and the qt
library tweaks it may still have bugs.

But it looks promising as it has been build against the distros qt libs
versions. So Qt4.x

Next would be to pack that and make it available. But this comes the next days.
For now I check whether the other packages still build and work.

[jr] Re: povmodeler [2300 days 23 hours and 23 minutes ago]

Thu, 19 Dec 2019 17:35:01 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> I worked on the slackware-14.x support and got an executable. But its not good
> enough to let it out into the wild.

:-)

> But it builds with Qt4 and even the OpenGL things seems to work. But docking of
> the widgets and some file-loading things are not ready.

thanks.  keep "us" in the loop, please.


regards, jr.

[simbad] Re: povmodeler [2301 days 1 hour and 38 minutes ago]

Thu, 19 Dec 2019 15:20:00 GMT

I worked on the slackware-14.x support and got an executable. But its not good
enough to let it out into the wild.

But it builds with Qt4 and even the OpenGL things seems to work. But docking of
the widgets and some file-loading things are not ready.

[jr] Re: povmodeler [2326 days and 28 minutes ago]

Sun, 24 Nov 2019 16:30:00 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "simbad" <Han### [at] gmxde> wrote:
> > > "jr" <cre### [at] gmailcom> wrote:
> > > > "simbad" <Han### [at] gmxde> wrote:
> .......
> Do you have an unchanged 14.1 14.2 installation? As this would make things more
> and more complicated.

:-)

> 14.2 uses qt-4.8.7
> 14.1 uses qt-4.8.5 and additional has cmake version 2.8.12

I have (on the 14.1 box) both qt-4.8.7 and qt5-5.7.1.

> So even I want many systems supported it takes more and more effort to get it
> compiled.


regards, jr.

[simbad] Re: povmodeler [2326 days 4 hours and 3 minutes ago]

Sun, 24 Nov 2019 12:55:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "simbad" <Han### [at] gmxde> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > "simbad" <Han### [at] gmxde> wrote:

.......

> > > thanks, both of you.  it'll have to wait a while though, busy with other stuff.
> > >
> > What slackware is it? 14.x? Think this was the last release. So maybe I give it
> > a try. Used slackware a long time. But need to check how to create a package
> > there. Never did before.
>
> yes, both 14.1 and 14.2.  for the command see "man 8 makepkg".  no rush.
>
>
> regards, jr.

Do you have an unchanged 14.1 14.2 installation? As this would make things more
and more complicated.

14.2 uses qt-4.8.7
14.1 uses qt-4.8.5 and additional has cmake version 2.8.12

So even I want many systems supported it takes more and more effort to get it
compiled.

[jr] Re: povmodeler [2332 days 6 hours and 58 minutes ago]

Mon, 18 Nov 2019 10:00:00 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "simbad" <Han### [at] gmxde> wrote:
> > > Dick Balaska <dic### [at] buckosoftcom> wrote:
> > > > On 11/17/19 4:34 PM, jr wrote:
> > > > > sounds promising.  will you, in due course, release a source tarball?  (the
> > > > > preferred format for Slackware)
> > > >
> > > > You could clone the source
> > > >
> > > > https://github.com/tribad/povmodeler
> > > >
> > > > --
> > > > dik
> > > > Rendered 24,551,424,000 of 40,928,716,800 pixels (59%)
> > >
> > > Yeah....
> > > The packages are produced from the branch named "original".
> >
> > thanks, both of you.  it'll have to wait a while though, busy with other stuff.
> >
> What slackware is it? 14.x? Think this was the last release. So maybe I give it
> a try. Used slackware a long time. But need to check how to create a package
> there. Never did before.

yes, both 14.1 and 14.2.  for the command see "man 8 makepkg".  no rush.


regards, jr.

[simbad] Re: povmodeler [2332 days 9 hours and 53 minutes ago]

Mon, 18 Nov 2019 07:05:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "simbad" <Han### [at] gmxde> wrote:
> > Dick Balaska <dic### [at] buckosoftcom> wrote:
> > > On 11/17/19 4:34 PM, jr wrote:
> > > > sounds promising.  will you, in due course, release a source tarball?  (the
> > > > preferred format for Slackware)
> > >
> > > You could clone the source
> > >
> > > https://github.com/tribad/povmodeler
> > >
> > > --
> > > dik
> > > Rendered 24,551,424,000 of 40,928,716,800 pixels (59%)
> >
> > Yeah....
> > The packages are produced from the branch named "original".
>
> thanks, both of you.  it'll have to wait a while though, busy with other stuff.
>
>
> regards, jr.

What slackware is it? 14.x? Think this was the last release. So maybe I give it
a try. Used slackware a long time. But need to check how to create a package
there. Never did before.

[jr] Re: povmodeler [2332 days 17 hours and 53 minutes ago]

Sun, 17 Nov 2019 23:05:00 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> Dick Balaska <dic### [at] buckosoftcom> wrote:
> > On 11/17/19 4:34 PM, jr wrote:
> > > sounds promising.  will you, in due course, release a source tarball?  (the
> > > preferred format for Slackware)
> >
> > You could clone the source
> >
> > https://github.com/tribad/povmodeler
> >
> > --
> > dik
> > Rendered 24,551,424,000 of 40,928,716,800 pixels (59%)
>
> Yeah....
> The packages are produced from the branch named "original".

thanks, both of you.  it'll have to wait a while though, busy with other stuff.


regards, jr.

[simbad] Re: povmodeler [2332 days 18 hours and 43 minutes ago]

Sun, 17 Nov 2019 22:15:03 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "simbad" <Han### [at] gmxde> wrote:
>
> > > Installed a Linux Mint 18.3 and checked it. I would not expect it to run. I can
> > > not even build it on this distro. Should not be a big problem. But must check
> > > how to not break my build environment.
> >
> > Completed. Even it feels like a hack. But it produced something. The packages
> > have been updated and a package for the Mint-18.3 is here
>
> Well it works, so your hacks are good   :)
>
> I have to set up the environment variables so that it can find a version of
> POV-Ray to use, so a pointer to any documentation this thing used to have would
> be sweet!
> Also, if there are some .kpm files to use as examples, anyone new to this would
> likely find those useful.
>
> Super work!    Glad to finally have a running example of this to play with.
> Thanks so much for what must be a LOT of unseen work in the background.

Examples and such things can be found in /usr/share/povmodeler

[simbad] Re: povmodeler [2332 days 18 hours and 48 minutes ago]

Sun, 17 Nov 2019 22:10:00 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 11/17/19 4:34 PM, jr wrote:
> > hi,
>
> >
> > sounds promising.  will you, in due course, release a source tarball?  (the
> > preferred format for Slackware)
> >
>
> You could clone the source
>
> https://github.com/tribad/povmodeler
>
> --
> dik
> Rendered 24,551,424,000 of 40,928,716,800 pixels (59%)

Yeah....
The packages are produced from the branch named "original".

All other branches are somewhat out of sync. So unusable, already modified a
lot.

[Dick Balaska] Re: povmodeler [2332 days 19 hours and 14 minutes ago]

Sun, 17 Nov 2019 21:43:51 GMT

On 11/17/19 4:34 PM, jr wrote:
> hi,

> 
> sounds promising.  will you, in due course, release a source tarball?  (the
> preferred format for Slackware)
> 

You could clone the source

https://github.com/tribad/povmodeler

-- 
dik
Rendered 24,551,424,000 of 40,928,716,800 pixels (59%)

[jr] Re: povmodeler [2332 days 19 hours and 23 minutes ago]

Sun, 17 Nov 2019 21:35:01 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> "simbad" <Han### [at] gmxde> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > "simbad" <Han### [at] gmxde> wrote:
> > > > Did some changes to the installation places and give the packages a better
> > > > version info.
> > >
> > > > Check it!
> > >
> > > Nice!   I will.
> > > inxi -Fx gives me Linux Mint 18.3 Sylvia - I'll let you know how the debian
> > > packages work out with these.
> >
> > Installed a Linux Mint 18.3 and checked it. I would not expect it to run. I can
> > not even build it on this distro. Should not be a big problem. But must check
> > how to not break my build environment.
>
> Completed. Even it feels like a hack. But it produced something. The packages
> have been updated and a package for the Mint-18.3 is here
>
> https://www.simulated-universe.de/povmodeler-1.1.4-linuxmint-18.3.deb
>
> But as I checked it only in the debian-10 VM and my own fedora-30 it may fail to
> work.

sounds promising.  will you, in due course, release a source tarball?  (the
preferred format for Slackware)


regards, jr.

[Bald Eagle] Re: povmodeler [2332 days 19 hours and 58 minutes ago]

Sun, 17 Nov 2019 21:00:08 GMT

"simbad" <Han### [at] gmxde> wrote:

> > Installed a Linux Mint 18.3 and checked it. I would not expect it to run. I can
> > not even build it on this distro. Should not be a big problem. But must check
> > how to not break my build environment.
>
> Completed. Even it feels like a hack. But it produced something. The packages
> have been updated and a package for the Mint-18.3 is here

Well it works, so your hacks are good   :)

I have to set up the environment variables so that it can find a version of
POV-Ray to use, so a pointer to any documentation this thing used to have would
be sweet!
Also, if there are some .kpm files to use as examples, anyone new to this would
likely find those useful.

Super work!    Glad to finally have a running example of this to play with.
Thanks so much for what must be a LOT of unseen work in the background.

[simbad] Re: povmodeler [2332 days 21 hours and 58 minutes ago]

Sun, 17 Nov 2019 19:00:01 GMT

"simbad" <Han### [at] gmxde> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "simbad" <Han### [at] gmxde> wrote:
> > > Did some changes to the installation places and give the packages a better
> > > version info.
> >
> > > Check it!
> >
> > Nice!   I will.
> > inxi -Fx gives me Linux Mint 18.3 Sylvia - I'll let you know how the debian
> > packages work out with these.
>
> Installed a Linux Mint 18.3 and checked it. I would not expect it to run. I can
> not even build it on this distro. Should not be a big problem. But must check
> how to not break my build environment.

Completed. Even it feels like a hack. But it produced something. The packages
have been updated and a package for the Mint-18.3 is here

https://www.simulated-universe.de/povmodeler-1.1.4-linuxmint-18.3.deb

But as I checked it only in the debian-10 VM and my own fedora-30 it may fail to
work.

[simbad] Re: povmodeler [2332 days 22 hours and 58 minutes ago]

Sun, 17 Nov 2019 18:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "simbad" <Han### [at] gmxde> wrote:
> > Did some changes to the installation places and give the packages a better
> > version info.
>
> > Check it!
>
> Nice!   I will.
> inxi -Fx gives me Linux Mint 18.3 Sylvia - I'll let you know how the debian
> packages work out with these.

Installed a Linux Mint 18.3 and checked it. I would not expect it to run. I can
not even build it on this distro. Should not be a big problem. But must check
how to not break my build environment.

[Bald Eagle] Re: povmodeler [2333 days 2 hours and 48 minutes ago]

Sun, 17 Nov 2019 14:10:00 GMT

"simbad" <Han### [at] gmxde> wrote:
> Did some changes to the installation places and give the packages a better
> version info.

> Check it!

Nice!   I will.
inxi -Fx gives me Linux Mint 18.3 Sylvia - I'll let you know how the debian
packages work out with these.

[simbad] Re: povmodeler [2333 days 5 hours and 58 minutes ago]

Sun, 17 Nov 2019 11:00:01 GMT

Did some changes to the installation places and give the packages a better
version info.

https://www.simulated-universe.de/povmodeler-1.1.4-debian-10.deb
https://www.simulated-universe.de/povmodeler-1.1.4-linuxmint-19.1.deb
https://www.simulated-universe.de/povmodeler-1.1.4-linuxmint-19.2.deb
https://www.simulated-universe.de/povmodeler-1.1.4-opensuse-leap-15.1.rpm
https://www.simulated-universe.de/povmodeler-1.1.4-fedora-30.rpm

Check it!

[simbad] Re: povmodeler [2334 days and 23 minutes ago]

Sat, 16 Nov 2019 16:35:01 GMT

I now have a build environment to produce the various packages.

They get build on the original distros. So it should be match far better than in
the first version


https://www.simulated-universe.de/povmodeler-0.1-debian-10.deb

https://www.simulated-universe.de/povmodeler-0.1-linuxmint-19.1.deb

https://www.simulated-universe.de/povmodeler-0.1-linuxmint-19.2.deb

https://www.simulated-universe.de/povmodeler-0.1-opensuse-leap-15.1.rpm


As I mostly work on weekend on this project its going on slowly.
I did not change anything on the installation places and the like. Maybe doing
this tomorrow.

[simbad] Re: povmodeler [2346 days 22 hours and 18 minutes ago]

Sun, 3 Nov 2019 18:40:00 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:

> *You* shouldn't have to do anything.  It's up to the dev to try to
> broaden his potential user base (which is pretty small to begin with)
> and not use bleeding edge versions.  If he is cutting debian versions,
> he needs to use supported debian versions as much as possible.
>
> (Unless absolutely necessary, which in this case is a port from 2005's
> Qt 3, so I doubt there is anything Qt 5.11 specific)
>

> --
> dik
> Rendered 22,077,619,200 of 40,928,716,800 pixels (53%)

Full ack to this. It is my responsibility to make the packages work. But as its
the first time doing that, I need some more days to upgrade my dev environment.
I think it would be a good idea to have some different systems available to not
only check the installation procedure but the build process as well.

To setup a specific distribution into a VM only takes an hour or so. It is ok to
support my efforts, but I need the VMs anyway. So dont risk your own
installation.

That I used a debian-10 busty as my first debian environment, that has the
qt5.11 libs, was sheer coincidence. But, hey. No problem doing it again with a
mint 19.2 and mint 19.1 next. The VMs already up.

[Dick Balaska] Re: povmodeler [2347 days and 58 minutes ago]

Sun, 3 Nov 2019 15:59:40 GMT

On 11/3/19 9:27 AM, Bald Eagle wrote:
> 
> Dick Balaska <dic### [at] buckosoftcom> wrote:
> 
>> I have libglx0 and libopengl0 [1], but I'm not sure where they came
>> from. AFAICT they are in the normal mint/ubuntu repos.
> 
> I haven't done a lot with the PPA / repositories  --- I've just sort of cut and
> pasted command line stuff from some betty crocker web pages as I've needed them,
> so I don't know which ones I'm plugged into and which ones are "the normal
> ones".

/etc/apt/sources.list.d/official-package-repositories.list
contains the normal ones.  Any you add are in their own file, like 
qtpovray-qtpovray-bionic.list

> 
>> The Qt >= 5.11 is problematic.  That is way too new to be in any debian
>> distros. Baldy is Mint 19.1 with QT 5.5.  I am Mint 19.2 (newest
>> version, 2 months old) and that is QT 5.9.
> 
> I'm presuming that I need to do more than just a simple "sudo apt-get upgrade",
> since I've done that a few times in recent memory, and it looks like I'm still
> lagging behind you, Speedy.

*You* shouldn't have to do anything.  It's up to the dev to try to 
broaden his potential user base (which is pretty small to begin with) 
and not use bleeding edge versions.  If he is cutting debian versions, 
he needs to use supported debian versions as much as possible.

(Unless absolutely necessary, which in this case is a port from 2005's 
Qt 3, so I doubt there is anything Qt 5.11 specific)

> 
> With regard to QTPOV-Ray:  I find that - too often - I'm doing something that
> pastes a bit of copied text into my scene in what looks like random places.
> Maybe I'm clicking a mouse button or using a keystroke when I'm actually in the
> editor but I think I'm in the browser window or the system's text editor...
> But I was wondering if any such thing ever happened to you.
> I'm forever scratching my head, wondering "How did THAT get in there...?"
> That mouse-click-paste is a dangerously easy thing to inadvertently do.
> Can I disable?

That middle-mouse-button-paste thing is indeed a pita, and really 
useless.  It is left over from the '80s and I can't believe it's still a 
thing.
I do it rarely, accidentally, of course.  I looked at disabling it, it's 
not easy and doesn't really work for me.  Solution: Don't do that.

-- 
dik
Rendered 22,077,619,200 of 40,928,716,800 pixels (53%)

[jr] Re: povmodeler [2347 days 1 hour and 13 minutes ago]

Sun, 3 Nov 2019 15:45:01 GMT

hi,

(forgot)

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> Ever since I tried using Redshift to relieve some eye strain and it took me
> forever to shut it off (I think I resorted to ps, grep, and "kill -9 [pid]"  :D
> ) I haven't fiddled with the greebles and frobs much...

there's also 'killall' which has the advantage of taking names, eg killall
redshift.

personally, I prefer the 'kill -s SIG pid' notation.  safer in use, imo.

regards, jr.

[Bald Eagle] Re: povmodeler [2347 days 2 hours and 28 minutes ago]

Sun, 3 Nov 2019 14:30:01 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:

> I have libglx0 and libopengl0 [1], but I'm not sure where they came
> from. AFAICT they are in the normal mint/ubuntu repos.

I haven't done a lot with the PPA / repositories  --- I've just sort of cut and
pasted command line stuff from some betty crocker web pages as I've needed them,
so I don't know which ones I'm plugged into and which ones are "the normal
ones".

> The Qt >= 5.11 is problematic.  That is way too new to be in any debian
> distros. Baldy is Mint 19.1 with QT 5.5.  I am Mint 19.2 (newest
> version, 2 months old) and that is QT 5.9.

I'm presuming that I need to do more than just a simple "sudo apt-get upgrade",
since I've done that a few times in recent memory, and it looks like I'm still
lagging behind you, Speedy.

Mint 19.3 is scheduled for December.  Maybe I'll figure out how to install that
and see if it fixes some things...
https://www.omgubuntu.co.uk/2019/10/linux-mint-19-3-tricia-release-features

With regard to QTPOV-Ray:  I find that - too often - I'm doing something that
pastes a bit of copied text into my scene in what looks like random places.
Maybe I'm clicking a mouse button or using a keystroke when I'm actually in the
editor but I think I'm in the browser window or the system's text editor...
But I was wondering if any such thing ever happened to you.
I'm forever scratching my head, wondering "How did THAT get in there...?"
That mouse-click-paste is a dangerously easy thing to inadvertently do.
Can I disable?

> [1] $ apt-cache show libglx0

My terminal typeface has that nice "dotted zero", but my GUI typeface seems to
use one that makes it look too much like O.  :|

Ever since I tried using Redshift to relieve some eye strain and it took me
forever to shut it off (I think I resorted to ps, grep, and "kill -9 [pid]"  :D
) I haven't fiddled with the greebles and frobs much...

[simbad] Re: povmodeler [2347 days 7 hours and 8 minutes ago]

Sun, 3 Nov 2019 09:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "simbad" <Han### [at] gmxde> wrote:
> > I did create a debian-10 package.
> > Could be downloaded here https://simulated-universe.de/povmodeler-0.1-Linux.deb
> >
> > This is my first try ever to create a debian package. It will evolve over time.
>
> I opened it in Mint's Package Installer, and got:
> "Error: dependency is not satisfiable: libglx0"
>
> I tried sudo apt-get install libglx0 (and libglx and libgl) but it couldn't find
> any such package to install.   So I'm not sure what I need to install or where
> to install it from...
>
> then I tried this:
>
> sudo dpkg -i povmodeler-0.1-Linux.deb
> [sudo] password for oem:
> Selecting previously unselected package povmodeler.
> (Reading database ... 288574 files and directories currently installed.)
> Preparing to unpack povmodeler-0.1-Linux.deb ...
> Unpacking povmodeler (0.1) ...
> dpkg: dependency problems prevent configuration of povmodeler:
>  povmodeler depends on libglx0; however:
>   Package libglx0 is not installed.
>  povmodeler depends on libopengl0; however:
>   Package libopengl0 is not installed.
>  povmodeler depends on libqt5core5a (>= 5.11.0~rc1); however:
>   Version of libqt5core5a:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
>  povmodeler depends on libqt5gui5 (>= 5.7.0); however:
>   Version of libqt5gui5:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
>  povmodeler depends on libqt5widgets5 (>= 5.11.0~rc1); however:
>   Version of libqt5widgets5:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
>
> I'll work on it for a little while, but I'm trying this at the end of the day...
> :O

I already setup some more VMs. I create these packages soon for your OS. So
please tell me what OS you use.

[Dick Balaska] Re: povmodeler [2347 days 11 hours and 25 minutes ago]

Sun, 3 Nov 2019 05:32:54 GMT

On 11/3/19 1:29 AM, Dick Balaska wrote:

> 
> Another example is, your icons aren't quite right. These need to move:
> hi16-app-kpovmodeler.png /usr/share/icons/hicolor/16x16/povmodeler.png
> hi22-app-kpovmodeler.png /usr/share/icons/hicolor/22x22/povmodeler.png
> hi32-app-kpovmodeler.png /usr/share/icons/hicolor/32x32/povmodeler.png
> hi48-app-kpovmodeler.png /usr/share/icons/hicolor/48x48/povmodeler.png

Sorry, these are wrong.  The correct directories are

/usr/share/icons/hicolor/16x16/apps/povmodeler.png
/usr/share/icons/hicolor/22x22/apps/povmodeler.png

etc.
-- 
dik
Rendered 22,077,619,200 of 40,928,716,800 pixels (53%)

[Dick Balaska] Re: povmodeler [2347 days 11 hours and 28 minutes ago]

Sun, 3 Nov 2019 05:29:39 GMT

On 11/2/19 9:53 PM, Bald Eagle wrote:
> 
> "simbad" <Han### [at] gmxde> wrote:
>> I did create a debian-10 package.
>> Could be downloaded here https://simulated-universe.de/povmodeler-0.1-Linux.deb
>>
>> This is my first try ever to create a debian package. It will evolve over time.
> 
> I opened it in Mint's Package Installer, and got:
> "Error: dependency is not satisfiable: libglx0"
> 
> I tried sudo apt-get install libglx0 (and libglx and libgl) but it couldn't find
> any such package to install.   So I'm not sure what I need to install or where
> to install it from...
> 
> then I tried this:
> 
> sudo dpkg -i povmodeler-0.1-Linux.deb
> [sudo] password for oem:
> Selecting previously unselected package povmodeler.
> (Reading database ... 288574 files and directories currently installed.)
> Preparing to unpack povmodeler-0.1-Linux.deb ...
> Unpacking povmodeler (0.1) ...
> dpkg: dependency problems prevent configuration of povmodeler:
>   povmodeler depends on libglx0; however:
>    Package libglx0 is not installed.
>   povmodeler depends on libopengl0; however:
>    Package libopengl0 is not installed.
>   povmodeler depends on libqt5core5a (>= 5.11.0~rc1); however:
>    Version of libqt5core5a:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
>   povmodeler depends on libqt5gui5 (>= 5.7.0); however:
>    Version of libqt5gui5:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
>   povmodeler depends on libqt5widgets5 (>= 5.11.0~rc1); however:
>    Version of libqt5widgets5:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
> 
> I'll work on it for a little while, but I'm trying this at the end of the day...
> :O
> 
> 

I have libglx0 and libopengl0 [1], but I'm not sure where they came 
from. AFAICT they are in the normal mint/ubuntu repos. The home page 
listed below contains just the source, not a .deb package.  The only 
custom repos in /etc/apt/sources.list.d point to my own stuff (like 
qtpovray).

The Qt >= 5.11 is problematic.  That is way too new to be in any debian 
distros. Baldy is Mint 19.1 with QT 5.5.  I am Mint 19.2 (newest 
version, 2 months old) and that is QT 5.9.

Simbad, my reading of
https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html#cmake-single
says you ran some cmake command which generated the debian folder, then 
you ran something else to build the .deb.  You should edit the 
debian/control file and remove the versions from the dependencies and 
try to let the packager figure it out.
You run the risk of using a qt5 feature newer than 5.5, but it's a low 
risk.  I had a couple of issues solved like this:
https://github.com/dickbalaska/qtpovray/blob/qtpovray/qt/gui/editor/codeeditor.cpp#L114

qtpovray's control looks like this:
https://github.com/dickbalaska/qtpovray/blob/qtpovray/debian/control

I find it mush easier to keep the debian folder around as a native part 
of the source tree rather than continually recreating and editing them.

Another example is, your icons aren't quite right. These need to move:
hi16-app-kpovmodeler.png /usr/share/icons/hicolor/16x16/povmodeler.png
hi22-app-kpovmodeler.png /usr/share/icons/hicolor/22x22/povmodeler.png
hi32-app-kpovmodeler.png /usr/share/icons/hicolor/32x32/povmodeler.png
hi48-app-kpovmodeler.png /usr/share/icons/hicolor/48x48/povmodeler.png

and then in your povmodeler.desktop the icon reference is just 
povmodeler.  You can either hack debian/rules to move and rename them, 
like this:
https://github.com/dickbalaska/slyther-debian/blob/master/rules
or just reorg them in the source tree, and reference them normally.

---

[1] $ apt-cache show libglx0
Package: libglx0
Architecture: amd64
Version: 1.0.0-2ubuntu2.3
Multi-Arch: same
Priority: extra
Section: libs
Source: libglvnd
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubu### [at] listsubuntucom>
Original-Maintainer: Debian X Strike Force <deb### [at] listsdebianorg>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 90
Depends: libc6 (>= 2.14), libglvnd0 (= 1.0.0-2ubuntu2.3), libx11-6 (>= 
2:1.4.99.1), libglx-mesa0
Breaks: libgl1-mesa-glx (<< 18.0.5-0ubuntu0~18.04), libglvnd0 (<< 
0.2.999+git20170201-1)
Replaces: libgl1-mesa-glx (<< 18.0.5-0ubuntu0~18.04), libglvnd0 (<< 
0.2.999+git20170201-1)
Filename: pool/main/libg/libglvnd/libglx0_1.0.0-2ubuntu2.3_amd64.deb
Size: 28088
MD5sum: 312d48ae120aeba38800cf0eba14d139
SHA1: 65dfb7b0292b18c98710105fef352278df87c041
SHA256: 11d56b939271cac02b251dcc53630aec86aa66fc9433f3b63e3c6806580b20e8
Homepage: https://github.com/NVIDIA/libglvnd
Description-en: Vendor neutral GL dispatch library -- GLX support
  This is an implementation of the vendor-neutral dispatch layer for
  arbitrating OpenGL API calls between multiple vendors on a per-screen 
basis.
  .
  This package contains support for GLX.

-- 
dik
Rendered 22,077,619,200 of 40,928,716,800 pixels (53%)

[Bald Eagle] Re: povmodeler [2347 days 15 hours and 3 minutes ago]

Sun, 3 Nov 2019 01:55:01 GMT

"simbad" <Han### [at] gmxde> wrote:
> I did create a debian-10 package.
> Could be downloaded here https://simulated-universe.de/povmodeler-0.1-Linux.deb
>
> This is my first try ever to create a debian package. It will evolve over time.

I opened it in Mint's Package Installer, and got:
"Error: dependency is not satisfiable: libglx0"

I tried sudo apt-get install libglx0 (and libglx and libgl) but it couldn't find
any such package to install.   So I'm not sure what I need to install or where
to install it from...

then I tried this:

sudo dpkg -i povmodeler-0.1-Linux.deb
[sudo] password for oem:
Selecting previously unselected package povmodeler.
(Reading database ... 288574 files and directories currently installed.)
Preparing to unpack povmodeler-0.1-Linux.deb ...
Unpacking povmodeler (0.1) ...
dpkg: dependency problems prevent configuration of povmodeler:
 povmodeler depends on libglx0; however:
  Package libglx0 is not installed.
 povmodeler depends on libopengl0; however:
  Package libopengl0 is not installed.
 povmodeler depends on libqt5core5a (>= 5.11.0~rc1); however:
  Version of libqt5core5a:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
 povmodeler depends on libqt5gui5 (>= 5.7.0); however:
  Version of libqt5gui5:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.
 povmodeler depends on libqt5widgets5 (>= 5.11.0~rc1); however:
  Version of libqt5widgets5:amd64 on system is 5.5.1+dfsg-16ubuntu7.6.

I'll work on it for a little while, but I'm trying this at the end of the day...
:O

[simbad] Re: povmodeler [2348 days 7 hours and 58 minutes ago]

Sat, 2 Nov 2019 09:00:01 GMT

I did create a debian-10 package.
Could be downloaded here https://simulated-universe.de/povmodeler-0.1-Linux.deb

This is my first try ever to create a debian package. It will evolve over time.

RPM is coming next.

[simbad] Re: povmodeler [2349 days 20 hours and 8 minutes ago]

Thu, 31 Oct 2019 20:50:05 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 10/29/19 12:52 PM, simbad wrote:
> > On https://github.com/tribad/povmodeler/tree/original I have a version ready
> > that may do it on a debian installation.
>
> >
> > Please check it.
> >
> >
>
> What are you using for an IDE?
>
> --
> dik
> Rendered 21,270,988,800 of 40,928,716,800 pixels (51%)

Qtcreator

[Dick Balaska] Re: povmodeler [2349 days 20 hours and 26 minutes ago]

Thu, 31 Oct 2019 20:32:03 GMT

On 10/29/19 12:52 PM, simbad wrote:
> On https://github.com/tribad/povmodeler/tree/original I have a version ready
> that may do it on a debian installation.

> 
> Please check it.
> 
> 

What are you using for an IDE?

-- 
dik
Rendered 21,270,988,800 of 40,928,716,800 pixels (51%)

[simbad] Re: povmodeler [2352 days and 3 minutes ago]

Tue, 29 Oct 2019 16:55:01 GMT

On https://github.com/tribad/povmodeler/tree/original I have a version ready
that may do it on a debian installation.

I did checkout this branch on my debian-10 VM did a

make install

and afterwards find a povmodeler desktop icon in the gnome3 activities overview.
A click on the Icon starts the povmodeler.

Please check it.

[Bald Eagle] Re: numpy linalg.norm question [2352 days 14 hours and 48 minutes ago]

Tue, 29 Oct 2019 02:10:00 GMT

Ugh.
I also have this beauty to unravel:

np.array([[a * b for b in center] for a in center])

center is a 2D array / matrix


Here I'm truly lost.
I'll have to read that over 100 times and never know if I'm interpreting it the
right way.   :O

[Bald Eagle] numpy linalg.norm question [2352 days 15 hours and 8 minutes ago]

Tue, 29 Oct 2019 01:50:00 GMT

I'm working on converting a python script into SDL, and I have most of the
matrix operations worked out, and just need to do a few more things before I can
start debugging (because you KNOW it never works the first time.)

I wrote a Norm (_Array) macro to take each element of a 2D array, square it, and
sum all the squares, then take the square root of that sum.

I now have this in front of me:
#local err = np.linalg.norm(new_u - U);

Do I make a new array that has each element equaling _A[i][j]-_B[i][j] and then
take the norm of that?

Just checking with anyone running python and familiar enough to give a quick
confirmation one way or the other.

[simbad] Re: povmodeler [2352 days 22 hours and 48 minutes ago]

Mon, 28 Oct 2019 18:10:00 GMT

"simbad" <Han### [at] gmxde> wrote:
> I created a branch on my fork named 'original'.
> https://github.com/tribad/povmodeler/tree/original
> That contains a runnable, at least for me, version of my base. There are some
> changes already made to the source. But let us see how it work out.
>
> First thing is the building of the povmodeler. So I changed the CMakeLists.txt
>
> Please check. Ping!

I checked it on a debian-10 VM. Building is no problem if all standard packages
that are needed to build anything are available. But its crashing. Found the
point, but will fix it tomorrow.

[simbad] Re: povmodeler [2353 days 1 hour and 13 minutes ago]

Mon, 28 Oct 2019 15:45:01 GMT

I created a branch on my fork named 'original'.
https://github.com/tribad/povmodeler/tree/original
That contains a runnable, at least for me, version of my base. There are some
changes already made to the source. But let us see how it work out.

First thing is the building of the povmodeler. So I changed the CMakeLists.txt

Please check. Ping!

[simbad] Re: povmodeler [2353 days 2 hours and 18 minutes ago]

Mon, 28 Oct 2019 14:40:00 GMT

If you try that it will be best if I would give you starting point. As I merged
may way of a new UI into the master you will have only limited luck on building
something that will fit anyones need ;)

Will give a ping here, for all who think it is worth it.

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 10/27/19 11:13 AM, Dick Balaska wrote:
>
> >
> > Then I got a little depressed because that dead-ends my fork from yours
> > and eticres'.Â  But I will finish the debian package because I actually
> > have a couple of use cases for povmodeler coming up in my movie.
> >
> >
>
> Bleh, apparently I was working from the original eticre version.
> It still has a several KDEisms in it.
> I found yours at https://github.com/tribad/povmodeler
> and I'm going to punt my copy and start over from yours.
>
>
> --
> dik
> Rendered 18,496,512,000 of 40,928,716,800 pixels (45%)

[Dick Balaska] Re: povmodeler [2353 days 20 hours and 5 minutes ago]

Sun, 27 Oct 2019 20:53:00 GMT

On 10/27/19 11:13 AM, Dick Balaska wrote:

> 
> Then I got a little depressed because that dead-ends my fork from yours 
> and eticres'.Â  But I will finish the debian package because I actually 
> have a couple of use cases for povmodeler coming up in my movie.
> 
> 

Bleh, apparently I was working from the original eticre version.
It still has a several KDEisms in it.
I found yours at https://github.com/tribad/povmodeler
and I'm going to punt my copy and start over from yours.

-- 
dik
Rendered 18,496,512,000 of 40,928,716,800 pixels (45%)

[jr] Re: povmodeler [2353 days 21 hours and 3 minutes ago]

Sun, 27 Oct 2019 19:55:05 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 10/27/19 1:26 PM, simbad wrote:
> > And then we need to sort out together what kind of problems exist on building
> > this on different environments. I have no problems to install some different VMs
> > for checking it out.
> > An openSUSE VM already exists, but did not use it for installation tests. But
> > will do that next.
>
> povmodeler is just Qt.  Trolltech has worked out all of the building in
> different environments.
>
> qtpovray is a qmake based program.  The same source set builds and runs
> on Linux, Windows and whatever jr is running.

I think that if it builds/installs cleanly on Debian + BSD, it'll build and
install on pretty much any Linux.

(there's even a Linux VM on Chromebooks.  ;-))

> ...


regards, jr.

[Bald Eagle] Re: povmodeler [2353 days 21 hours and 8 minutes ago]

Sun, 27 Oct 2019 19:50:05 GMT

"simbad" <Han### [at] gmxde> wrote:

> As far as I have seen from the source code of my starting point there is no KDE
> dependency in the source anymore. So I would think its in the cmake. I did
> changed it for my own work in complete, but ignored the installation thing, as I
> am far away from working for my fork.

Hans-Juergen,

Thanks very much.   I just ran cmake ../ again and got the following output, if
this helps at all:

CMake Warning at CMakeLists.txt:26 (find_package):
  Could not find a package configuration file provided by "KF5Parts" with any
  of the following names:

    KF5PartsConfig.cmake
    kf5parts-config.cmake

  Add the installation prefix of "KF5Parts" to CMAKE_PREFIX_PATH or set
  "KF5Parts_DIR" to a directory containing one of the above files.  If
  "KF5Parts" provides a separate development package or SDK, be sure it has
  been installed.

CMake Error at CMakeLists.txt:27 (find_package):
  By not providing "FindKF5KIO.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "KF5KIO", but
  CMake did not find one.

  Could not find a package configuration file provided by "KF5KIO" with any
  of the following names:

    KF5KIOConfig.cmake
    kf5kio-config.cmake

  Add the installation prefix of "KF5KIO" to CMAKE_PREFIX_PATH or set
  "KF5KIO_DIR" to a directory containing one of the above files.  If "KF5KIO"
  provides a separate development package or SDK, be sure it has been
  installed.

-- Configuring incomplete, errors occurred!
See also
"/home/oem/Downloads/kpovmodeler-master/build/CMakeFiles/CMakeOutput.log".

(I'm still comparatively new to linux, and all that goes along with it.   But on
the plus side, I've been pretty much M$-free for months now. )

> And then we need to sort out together what kind of problems exist on building
> this on different environments.

Probably a good idea - it would be a very nice thing indeed if we could get a
poll of users and their current OS and POV-Ray versions.

> Second problem is about implementation of new features into the old code. This
> is somehow hard, because its a monolithic block of code, where lots of files
> must be changed for only adding a single POVray object.

Yes, I got the impression that even with POV-Ray itself, that sort of thing is
true.

Very old article:

https://www.researchgate.net/publication/234831963_Scientific_visualizations_with_POV-Ray

(See Table 1, page 6)

> Most of it is very early C++ code with near to no use of STL-Containers and
> modern C++ capabilities. I do not blame anyone for this, as I know from my own
> experience how less stable C++ has been around 2004, and earlier, when it comes
> to portability.
>
> But these times are gone now and I think its time to move on with the code.

Yes.

Of course, at this juncture, I would probably have a meeting of the minds with
the people trying to resurrect Moray, and see what can be shared and made
easier.

I'd also maybe take a look at EPSpline, and definitely Microsoft VISIO - which
is what I wish more people would use as inspiration and guidance.

I wish I had maintained my computer literacy and programming skills, but twists
of fate and graduate school in Chemistry didn't leave a lot of time for that
:(

Thanks for looking into this and trying to get it to work!   :)

Bill

[Dick Balaska] Re: povmodeler [2353 days 21 hours and 33 minutes ago]

Sun, 27 Oct 2019 19:25:12 GMT

On 10/27/19 1:26 PM, simbad wrote:

> Most of it is very early C++ code with near to no use of STL-Containers and
> modern C++ capabilities.
Don't use STL-Containers, use the Qt containers.  So much easier, and 
you don't need the nuclear launch codes just to iterate a list.

-- 
dik
Rendered 18,243,532,800 of 40,928,716,800 pixels (40%)

[Dick Balaska] Re: povmodeler [2353 days 21 hours and 35 minutes ago]

Sun, 27 Oct 2019 19:22:53 GMT

On 10/27/19 1:26 PM, simbad wrote:

> 
> And then we need to sort out together what kind of problems exist on building
> this on different environments. I have no problems to install some different VMs
> for checking it out.
> An openSUSE VM already exists, but did not use it for installation tests. But
> will do that next.

povmodeler is just Qt.  Trolltech has worked out all of the building in 
different environments.

qtpovray is a qmake based program.  The same source set builds and runs 
on Linux, Windows and whatever jr is running.

I'll finish my povmodeler->qmake exercise and see if you want to move on 
with that.

-- 
dik
Rendered 18,243,532,800 of 40,928,716,800 pixels (40%)

[simbad] Re: povmodeler [2353 days 23 hours and 28 minutes ago]

Sun, 27 Oct 2019 17:30:01 GMT

Ok,

to all here posting in this quiet few hours.

As far as I see, there are two different problems here. One is, that the
original source cannot be installed build without problems and run, as expected.

As far as I have seen from the source code of my starting point there is no KDE
dependency in the source anymore. So I would think its in the cmake. I did
changed it for my own work in complete, but ignored the installation thing, as I
am far away from working for my fork.

With my new ui already merged into the master I could only create a branch that
will produce my old starting point, that would be mostly the eticre repo.

And then we need to sort out together what kind of problems exist on building
this on different environments. I have no problems to install some different VMs
for checking it out.
An openSUSE VM already exists, but did not use it for installation tests. But
will do that next.

Second problem is about implementation of new features into the old code. This
is somehow hard, because its a monolithic block of code, where lots of files
must be changed for only adding a single POVray object.

Most of it is very early C++ code with near to no use of STL-Containers and
modern C++ capabilities. I do not blame anyone for this, as I know from my own
experience how less stable C++ has been around 2004, and earlier, when it comes
to portability.

But these times are gone now and I think its time to move on with the code.

[Bald Eagle] Re: povmodeler [2354 days and 38 minutes ago]

Sun, 27 Oct 2019 16:20:01 GMT

"jr" <cre### [at] gmailcom> wrote:

> > would be interested in some new UI that should lead to new features.
> >
> > So please give me some hint.

Yes.   I recently tried to install povmodeler, with no success.
It would be great if I had even a basic version that was easy to install on
linux Mint.  I tried to install kde - but that went nowhere fast.

> I removed the old version, which _claimed_ to be KDE-free, only a few weeks ago.
>  nevertheless, it would be good, perhaps, if you could write about your progress
> in the newsgroups, I'm sure there'll be some interest.

There are a lot of projects that make sporadic progress - either to address some
sort of "I wish I had a modeler to do this" issue, or to try to implement a
simple modeler for a handful of objects.
I'm halfway through the circle/tangent thing for prisms myself, and that may
still take some time before It's ready for use/abuse testing.

Please, by all means, get something installable and useable out to the community
- I get the feeling that there are a lot of people who lurk or use POV-Ray but
are not active participants in the forum.

[jr] Re: povmodeler [2354 days 1 hour and 43 minutes ago]

Sun, 27 Oct 2019 15:15:01 GMT

hi,

"simbad" <Han### [at] gmxde> wrote:
> ...
> But after a week of good progress I am afraid that I started a work nobody will
> ever use. So it would be interesting to know if anyone is using the original and
> would be interested in some new UI that should lead to new features.
>
> So please give me some hint.

I removed the old version, which _claimed_ to be KDE-free, only a few weeks ago.
 nevertheless, it would be good, perhaps, if you could write about your progress
in the newsgroups, I'm sure there'll be some interest.

regards, jr.

[Dick Balaska] Re: povmodeler [2354 days 1 hour and 44 minutes ago]

Sun, 27 Oct 2019 15:13:29 GMT

On 10/27/19 9:17 AM, simbad wrote:

> 
> So please give me some hint.

I saw a comment/request for someone to turn this into a debian package, 
so I started to do that.  The first thing I did though was to rearrange 
the single directory of foo into a Qt layout.  i.e. ./source 
./resources and now I'm adding a qmake povmodeler.pro file.

Then I got a little depressed because that dead-ends my fork from yours 
and eticres'.  But I will finish the debian package because I actually 
have a couple of use cases for povmodeler coming up in my movie.

-- 
dik
Rendered 18,243,532,800 of 40,928,716,800 pixels (40%)

[simbad] povmodeler [2354 days 3 hours and 38 minutes ago]

Sun, 27 Oct 2019 13:20:01 GMT

Hello all,

I did a fork of eticres excelent work, https://github.com/eticre/povmodeler, on
removing the KDE stuff from the original source and moving the qt code to some
modern version.

As I fixed an exception on closing the library browser I do not only tried to
prevent the situation but to understand how this could happen.
I found that the particular object involved gets deleted while executing its own
destructor. I then tried to find the cause for this behaviour and
failed on understanding the code and what parts are done where.

After some code exploration tours, and some mild changes, I thought the best
would be to re-new the UI.
The original code is nearly 20 years old and realy needs an upgrade. So I went
on with the fork. First thing was to isolate the model store from the UI. This
is already done and loading some examples works.

But after a week of good progress I am afraid that I started a work nobody will
ever use. So it would be interesting to know if anyone is using the original and
would be interested in some new UI that should lead to new features.

So please give me some hint.

[Bald Eagle] Re: "circular" arrays [2359 days 16 hours and 48 minutes ago]

Tue, 22 Oct 2019 00:10:01 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

Thanks for the code and the link  :)

I do like that we have a lot of people who design and write include files and
code snippets, however much of what I'm musing about are additions to the source
code.

And that's for several reasons:

1.  It will be well-established, working, tested, reliable code to perform a
specific task in "the right way".

2.  and therefore, the [new] user, or experienced user who just doesn't have the
desire to write or track down such code will have it embedded into POV-Ray
already

3. and it follows along with the concept of "inseparability" - detachable things
like scene and include files get lost, forgotten, and even deleted.

4. Sometimes certain things are faster, because they are compiled code, and SDL
can be slow


So, I definitely think that plenty of scenes and macros and functions and
include files ought to be written and developed - but my wish is to see them
constantly being looked at for inclusion into subsequent versions.

[Bald Eagle] Re: APPEND debug to file? [2359 days 23 hours and 18 minutes ago]

Mon, 21 Oct 2019 17:40:01 GMT

"green" <rov### [at] gmailcom> wrote:

> http://wiki.povray.org/content/Reference:Text_Output_Options
>
> Append_File=true   Enable appending to any files that the above streams are
>                      being directed to.
> Append_File=false  Turn off appending to streams.
> +GP                Same as Append_File=true
> -GP                Same as Append_File=false

So apparently I somehow missed that part  :O

Thanks!   I will give that a go in some of my further work   :)

[green] Re: APPEND debug to file? [2360 days 4 hours and 48 minutes ago]

Mon, 21 Oct 2019 12:10:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I was just perusing last night's work on analyzing and debugging the radial
> pattern, and as many people have probably experienced - some sort of
> documentation of the history of the debugging would be useful.
>
> I looked over at:
> https://www.povray.org/documentation/view/3.6.1/222/
>
> and tried +GDfile, but it overwrites the file for each new render.
>
> Having some way to append to a file (with a date-time stamp?) would be useful.
>
> If there's a linux wizard about - I'm wondering if there's a way to scan the
> ..pov file being rendered with grep and output the lines with changes / or the
> lines marked with some sort of comment tag as well.
>
> That way one could spend their time and attention on trying to find and fix the
> problem, and then go back and have a record of what they did.
>
>
>

http://wiki.povray.org/content/Reference:Text_Output_Options

Append_File=true   Enable appending to any files that the above streams are
                     being directed to.
Append_File=false  Turn off appending to streams.
+GP                Same as Append_File=true
-GP                Same as Append_File=false

[jr] Re: APPEND debug to file? [2360 days 7 hours and 3 minutes ago]

Mon, 21 Oct 2019 09:55:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I was just perusing last night's work on analyzing and debugging the radial
> pattern, and as many people have probably experienced - some sort of
> documentation of the history of the debugging would be useful.
>
> I looked over at:
> https://www.povray.org/documentation/view/3.6.1/222/
>
> and tried +GDfile, but it overwrites the file for each new render.
>
> Having some way to append to a file (with a date-time stamp?) would be useful.

as a workaround, I might try to copy/move the file from a
'Post_{Frame,Scene}_Command' in an .ini.

> ...


regards, jr.

[Tor Olav Kristensen] Re: "circular" arrays [2360 days 18 hours and 13 minutes ago]

Sun, 20 Oct 2019 22:45:01 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
....
> I recommend that you look at how indexing of lists works in Python. I think that
> you will like it...

Here's some information about that:
https://railsware.com/blog/python-for-machine-learning-indexing-and-slicing-for-lists-tuples-strings-and-other-sequenti
al-types/

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Tor Olav Kristensen] Re: "circular" arrays [2360 days 19 hours and 33 minutes ago]

Sun, 20 Oct 2019 21:25:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I was working on a bit of code, it was late, and I thought perhaps that
> mod() would take a negative number and wrap it around to the "top", but it of
> course does not.  Then I got a "negative subscript" error when trying to address
> an array element.
>
> I was wondering if it might be sufficiently helpful so as to warrant an array
> type that would automatically wrap in either direction - perhaps with a warning
> that could be disabled.
>
> So an array with 5 elements (#declare array = array [5]) would yield Array[0] if
> Array[5] were addressed.   And likewise Array[-1] would yield Array [4].
>
> Something like carray for "cyclic array" or marray for "modulo array"...
>
> Perhaps a spiral array would find use in navigating data as well - a 2
> dimensional array where overrun in either direction in one dimension would shift
> over to the edge element in the next dimension.


Hi again Bill,

Here is my suggestion for how to do what (I believe) you want or need:

#version 3.7;

#declare Size = 5;
#declare Array1A = array[Size] { 4, 2, 5, 3, 7 };

#declare WrapFn = function(I) { mod(I + Size, Size) };

#debug "\n"

#debug "\n"
#debug concat("Array1A[0]: ", str(Array1A[WrapFn(0)], 0, 0))
#debug "\n"
#debug concat("Array1A[5]: ", str(Array1A[WrapFn(5)], 0, 0))
#debug "\n"
#debug concat("Array1A[4]: ", str(Array1A[WrapFn(4)], 0, 0))
#debug "\n"
#debug concat("Array1A[-1]: ", str(Array1A[WrapFn(-1)], 0, 0))
#debug "\n"

#debug "\n"
#error "To stop rendering"


So by wrapping array indices into function calls (or macro calls) you can remap
the the way arrays are indexed.

For 2D arrays you can do it like this:

#version 3.7;

#declare Size1 = 4;
#declare Size2 = 5;
#declare Array2A =
    array[Size1][Size2] {
        { 14,  2,  5, 13,  7 },
        {  0, 19, 11,  6, 15 },
        { 18,  4, 10,  8, 12 },
        { 16,  3,  9, 17,  1 }
    }
;

#declare Dim1Fn = function(I) { mod(I + Size1, Size1) };
#declare Dim2Fn = function(J) { mod(J + Size2, Size2) };

#debug "\n"
#debug concat("Array2A[2][3]: ", str(Array2A[Dim1Fn(2)][Dim2Fn(3)], 0, 0))
#debug "\n"
#debug concat("Array2A[6][-2]: ", str(Array2A[Dim1Fn(6)][Dim2Fn(-2)], 0, 0))
#debug "\n"

/*
// To get the spiralling behaviour you describe, you can insert your mapping
// magic into these two functions. The expressions for each of these may
// involve I, J, Size1 and Size2.
#declare Dim1_Fn = function(I, J) {  };
#declare Dim2_Fn = function(I, J) {  };

#debug "\n"
#debug concat("Array2A[2][3]: ", str(Array2A[Dim1_Fn(2, 3)][Dim2_Fn(2, 3)], 0,
0))
#debug "\n"
#debug concat("Array2A[6][-2]: ", str(Array2A[Dim1_Fn(6, -2)][Dim2_Fn(6, -2)],
0, 0))
#debug "\n"
*/

#debug "\n"
#error "To stop rendering"


BTW:

This may be relevant reading:
https://stackoverflow.com/questions/11720656/modulo-operation-with-negative-numbers

I recommend that you look at how indexing of lists works in Python. I think that
you will like it...

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] "circular" arrays [2360 days 21 hours and 18 minutes ago]

Sun, 20 Oct 2019 19:40:07 GMT

So, I was working on a bit of code, it was late, and I thought perhaps that
mod() would take a negative number and wrap it around to the "top", but it of
course does not.  Then I got a "negative subscript" error when trying to address
an array element.

I was wondering if it might be sufficiently helpful so as to warrant an array
type that would automatically wrap in either direction - perhaps with a warning
that could be disabled.

So an array with 5 elements (#declare array = array [5]) would yield Array[0] if
Array[5] were addressed.   And likewise Array[-1] would yield Array [4].

Something like carray for "cyclic array" or marray for "modulo array"...

Perhaps a spiral array would find use in navigating data as well - a 2
dimensional array where overrun in either direction in one dimension would shift
over to the edge element in the next dimension.

[Bald Eagle] APPEND debug to file? [2361 days 1 hour and 18 minutes ago]

Sun, 20 Oct 2019 15:40:01 GMT

So, I was just perusing last night's work on analyzing and debugging the radial
pattern, and as many people have probably experienced - some sort of
documentation of the history of the debugging would be useful.

I looked over at:
https://www.povray.org/documentation/view/3.6.1/222/

and tried +GDfile, but it overwrites the file for each new render.

Having some way to append to a file (with a date-time stamp?) would be useful.

If there's a linux wizard about - I'm wondering if there's a way to scan the
..pov file being rendered with grep and output the lines with changes / or the
lines marked with some sort of comment tag as well.

That way one could spend their time and attention on trying to find and fix the
problem, and then go back and have a record of what they did.



--------------------
Peripheral stuff:

Also of use would be - a way to mark certain sections of code or the text
representation of a function for output to #debug, or use in a text{} object.

What I mean by that, is akin to formula() or current() in OpenOffice.
Let's say that /~  ...  ~/ is a construct similar to /* ... */ for commenting.
Only instead of commenting out the enclosed code block, the included code gets
output to the #debug stream.

Let's say we have #declare Fx = function {sin (x)}
formula () would be able to take Fx as an argument and return "sin(x)" as text
for use in scene code or #debug output


current() outputs everything up to that point "on the current line"

So maybe something _like_ #declare SomeImportantParameter = Phi; /<

would serve a similar purpose - clearly not the exact concrete example I'm
proposing


Just emptying the brain for the record.

[Bonnette] Re: use of homogeneous matrix for transformations [2363 days 4 hours and 43 minutes ago]

Fri, 18 Oct 2019 12:15:00 GMT

I have found a couple of videos for my college course. But I'm not sure which
type or method to choose, while I'm aware of two of them so far. The first one
was tested, when we used a projective transformation here:
https://www.khanacademy.org/math/precalculus/x9e81a4f98389efdf:matrices/x9e81a4f98389efdf:matrices-as-transformations/v
/transforming-position-vector
https://writemyessaytoday.net/write-my-essay-in-12-hours

[Bald Eagle] Re: povmodeler [2377 days 16 hours and 48 minutes ago]

Fri, 4 Oct 2019 00:10:00 GMT

"eticre" <eti### [at] tinit> wrote:

> https://github.com/eticre/kpovmodeler.git
>
> git repo with kde dependences

Trying this on Linux Mint.

CMake Warning at CMakeLists.txt:26 (find_package):
  Could not find a package configuration file provided by "KF5Parts" with any
  of the following names:

    KF5PartsConfig.cmake
    kf5parts-config.cmake

  Add the installation prefix of "KF5Parts" to CMAKE_PREFIX_PATH or set
  "KF5Parts_DIR" to a directory containing one of the above files.  If
  "KF5Parts" provides a separate development package or SDK, be sure it has
  been installed.

CMake Error at CMakeLists.txt:27 (find_package):
  By not providing "FindKF5KIO.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "KF5KIO", but
  CMake did not find one.

  Could not find a package configuration file provided by "KF5KIO" with any
  of the following names:

    KF5KIOConfig.cmake
    kf5kio-config.cmake

  Add the installation prefix of "KF5KIO" to CMAKE_PREFIX_PATH or set
  "KF5KIO_DIR" to a directory containing one of the above files.  If "KF5KIO"
  provides a separate development package or SDK, be sure it has been
  installed.

-- Configuring incomplete, errors occurred!

[dick balaska] Re: [patch] Suggesting trivial patch (again) [2441 days 20 hours and 4 minutes ago]

Wed, 31 Jul 2019 20:53:23 GMT

On 7/31/19 6:20 AM, masonlava wrote:

POV-Ray does not directly support HP printers, only Centronics.  There
used to be a patch that added PCL-2 but it was never updated to color PCL-5.


-- 
dik
Rendered 1024 of 921600 pixels (0%)

[William F Pokorny] My ray tracing solver epiphany! [2480 days 5 hours and 18 minutes ago]

Sun, 23 Jun 2019 11:39:43 GMT

The Universe whispers, "You're working in a ray tracer." Ray tracing
equation generation, root isolation and root finding should be one
integral process.

Back in March I closed out the thread at:

http://news.povray.org/povray.binaries.images/thread/%3C5abe2bdc%241%40news.povray.org%3E/?ttop=427346&toff=150

after working a year on and off with POV-Ray's solvers. The updated
solvers were at a state where accuracy was as good as I thought it could
be. The plan was to work with the updates for a time while getting back
ray tracing and other ideas. I'd keep my eyes open for additional issues.

Those - few I suspect - following the solver related work and comments
at: https://github.com/POV-Ray/povray/pull/358 know I immediately found
an issue with photons and the diffuse_back.pov scene. The issue led me
to create similar photon test scenes for most shapes.

For shapes of equation orders > 2, the disheartening result was the new,
improved, accurate as can be solvers were not enough where rays start
far from the surface. With floats, on float hardware, surface root
accuracy from afar is ugly.

Thankfully, I created a polynomial torus test with major accuracy issues
while a similar scene using the regular torus object was OK. It's the
case that torus.cpp has a patch which, sometimes, moves the ray origin
closer to the first surface before calculating coefficients. This
greatly improves the accuracy of the ray-surface equation.

The patch isn't general to secondary rays, it's discontinuous in
application to outside, first surface rays and the effectiveness
degrades on other factors. Still, it often saves the day. I was looking
for something more general without luck, when it hit me: POV-Ray creates
the polynomial equations!

Today, we create coefficients for ray-surface equations and throw them
at various solvers. The solvers work on these equations blind to what
process created them and without ability to ask for better.

With respect to accuracy on float hardware, it's not the best approach.
Equation generation, root isolation and root finding should be one
mechanism.

Ray tracers can replace the mobius transformations used in Vincent,
Akritas, et al type solvers with ray-surface equation generation and
sign evaluation. Ray tracers - knowing the shape - can also jump to
conclusions without the need to isolate single roots. Odd root counts
for an even order shape mean we are inside the shape, for example.

The current approach isn't that pure and uses foreknowledge about the
shape to quickly localize and set intervals while creating additional
equations. I have a working TCL implementation for the torus.

For the results below, the torus is sitting in the xz plane with the ray
origin -1370.0 in x to the left and the ray direction to right (left
handed).

P = <-1370.0 0.0 0.0>
D = <1.0 0.0 0.0>
MajorRadius = <0.35>
MinorRadius = <0.2>

The ray-surface equation created is:

t^4 - 5480.0*t^3 + 11261399.675*t^2 - 10285411109.5*t + 3522753000007.5063

Using a couple solvers, we come up with four roots indicative of results
seen inside POV-Ray. For ray tracing purposes they're not very good and
we have limited ability to polish the roots due the created equation(a).

TCL quartic:

<1369.4485149222974 1369.8555365457344
1370.1444769215443 1370.5514716104242>

Sage's .roots (Berstein basis / de Casteljau...)

[(1369.45309378556, 1), (1369.83907617961, 1),
(1370.16093129266, 1), (1370.54689874217, 1)]

The new approach uses a quadratic solver to find ray-sphere
intersections bounding the torus. These are used to create a second
ray-torus equation for the same torus at the first intersection. A Sturm
chain related analysis gets done - one not requiring polynomial
evaluations - to set the number of roots at 0, 2 or 4. Knowing the root
count simplifies downstream code.

The rest leans on many solver techniques. The key extension being the
use of existing ray-surface equation generation to create multiple ray
equations shooting forward and backward from sample points along the
ray. Decisions about how to isolate roots are based on the coefficient
sign changes alone. The best part is the much more accurate, root-unique
equations are used when finding each root.

Torus results with new method:

1369.45, 1369.85, 1370.15, 1370.55 <--- Exact roots!

I'm encouraged. I think we've got a path to as much accuracy as float
based coefficient creation and calculation allow. I'm posting ahead of
an in POV-Ray implementation due being away for the next few weeks.

Might we make use of a, "regenerate coefficients and root polish"
technique too? Yes, I think we might as a near term(1) improvement.

Bill P.

(1) - The torus.cpp patch aside; At a distance of around 1400 to a unit
sized torus at the origin, today's solvers don't 'see' the correct
number of roots a surprising 4-5% of the time(a). Solvers usually see
roots exist and so find a first root to some rough value - and often
additional roots. This means the shape shows up - but with surfaces not
quite right. Plus, 1-2% of the time with near tangents, solvers miss
real roots. Rays deriving from inaccurate first intersections are worse
being based upon inaccurate first ray result.

(a) - It's not a solver problem! The accuracy isn't intrinsic to the
generated polynomial. In other words, available steps/precision are
today being wasted on empty distance to and between roots.

[Bald Eagle] df3, hf, patterns, functions, binary read/write,... [2491 days 17 hours and 28 minutes ago]

Tue, 11 Jun 2019 23:30:01 GMT

It seems to me that an often requested feature is to be able to have POV-Ray
smoothly "plot" x,y,z data in some way.

So, I was wondering how much development would be required to:

- Directly generate a grayscale image / pigment / pattern / function or
heightfield using array values, CSV files, or other easily user-generated data
source.

- import text data to generate a df3 density function

It just seems to me that when these binary file types are imported, that data
gets imported into some data structure, and it seems a short jump take data in
an existing 2D or 3D array and copy it over to an image_map or df3.

- read and write BINARY data directly from and to files, facilitating the
creation of required file types without the need to install software, acquire
proficiency in another language, it's syntax, etc.

Also of use here would be determining the type/cast of data, such that data
could be read from a file without prior knowledge of the exact file structure.
I believe there's been a related concern about determining if an identifier is a
vector or scalar.

Some sort of error handling would be extremely useful as well, such that
erroneous data could be rejected and just skipped instead of flat-out failing
the render, and this would be useful as a way to reset the file pointer and try
to read the correct data type (as a workaround).  One could also skip the usual
degenerate cylinders and cones, etc if desired, to simplify certain coding of
scenes.
And of course - the cryptic nature of the error messages is sometimes about as
illuminating as "Error 512".

[tTh] using rhe quality setting from a .pov file [2527 days 20 hours and 47 minutes ago]

Mon, 6 May 2019 20:10:52 GMT

Hello

I'm working on a scene with a lot of light, and rendering
take a lot of time, even in low quality to place the elements,
and I thought of a function, equivalent to 'clock' which
returns the value of the -Q parameter of the command line,
so I can do :

#if (quality > 5)
    light_source { ... }
#end

I diged through the documentation and found nothing.
Is it possible to plan this for a future version?
Is it easy to go into the source code to try to add
the function? And where to start?

tTh.


-- 
http://la.buvette.org/POV/Cloitre

[clipka] Re: Location of Noise() and VScale() in source? [2544 days and 58 minutes ago]

Sat, 20 Apr 2019 15:59:39 GMT

Am 20.04.2019 um 14:19 schrieb Bald Eagle:

> I think with fresh eyes, I see that Noise is a call to PortableNoise - so maybe
> that will let me trace the code  :)

(Technically, `Noise` _may or may not_ be a call to `PortableNoise` - 
that depends on how the binary is compiled, and possibly also the 
features of the CPU it is actually run on. But since it is always a call 
to either that function or an optimized variant that gives the same 
results (the infamous "optimized noise generator"), this distinction is 
only relevant when making changes to the function.)

> VScale is called from the Turbulence function in texture.cpp

My, that's some old code there!

`VScale(a,b,c)` was a function that implemented uniform linear scaling 
of a vector back in the days when we used the C-style 3-element array 
type `VECTOR` to store vectors. That type has been superseded by the 
class type `Vector3d`, which provides operator overloading for the same 
purpose, and instead of `VScale(a,b,c)` we would now write `a=b*c`.

(Also, the `Turbulence` function now resides in `noise.cpp`.)

[Bald Eagle] Re: Location of Noise() and VScale() in source? [2544 days 4 hours and 38 minutes ago]

Sat, 20 Apr 2019 12:20:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Hello Bill

Hi TOK, long time no see   :)
Hope you're doing well.

> There's a definition of Noise here:
> https://github.com/POV-Ray/povray/blob/master/source/core/material/noise.h#L196

excellent.
I think with fresh eyes, I see that Noise is a call to PortableNoise - so maybe
that will let me trace the code  :)

inline DBL Noise(const Vector3d& EPoint, int noise_generator) { return
PortableNoise(EPoint, noise_generator); }

> In which file did you see VScale ?

VScale is called from the Turbulence function in texture.cpp

[I don't actually do any real C++, but it looks like "const TURB *Turb" is
declaring use of a constant named TURB which comes from - a class (?) or a
struct (?) or an internal private part of another part of the code called "Turb"
and "dereferences" that with the * ?
Similar later on with "int Octaves=Turb->Octaves;", Lambda and Omega.
I have only the most tenuous grasp of the dot . and arrow -> operators at this
point.]

DBL Turbulence(const VECTOR EPoint, const TURB *Turb, int noise_generator)
{
 int i;
 DBL Lambda, Omega, l, o, value;
 VECTOR temp;
 int Octaves=Turb->Octaves;

 if (noise_generator>1)
 {
  value = (2.0 * Noise(EPoint, noise_generator) - 0.5);
  value = min(max(value,0.0),1.0);
 } else {
  value = Noise(EPoint, noise_generator);
 }

 l = Lambda = Turb->Lambda;
 o = Omega  = Turb->Omega;

 for (i = 2; i <= Octaves; i++)
 {
  VScale(temp,EPoint,l);
  if (noise_generator>1)
   value += o * (2.0 * Noise(temp, noise_generator) - 0.5);
 else
  value += o * Noise(temp, noise_generator);
  if (i < Octaves)
  {
   l *= Lambda;
   o *= Omega;
  }
 }
 return (value);
}

and it resides in /source/backend/math/vector.h

inline void VScale(SNGL_VECT a, const SNGL_VECT b, SNGL k)
{
 a[X] = b[X] * k;
 a[Y] = b[Y] * k;
 a[Z] = b[Z] * k;
}

> BTW: Have you ever tried Midnight Commander ?
> I find it very easy to use when searching through a lot of files.

Nope.  I honestly haven't had the energy and the ability to focus on meticulous
things like this for a while - just so much IRL.
Work, the Plague, car repairs, etc........................................

But I keep hanging on by my fingernails   ;)

I'll take a look at M.C. and see what it's like - thanks for the tip!

[Tor Olav Kristensen] Re: Location of Noise() and VScale() in source? [2544 days 13 hours and 23 minutes ago]

Sat, 20 Apr 2019 03:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I was just poking around in the turbulence code, and it references
>
> Noise ()
> and
> VScale ()
>
> I was wondering where those were located.
>
> I tried
>
> find -type f -exec grep -H ' Noise(' {} \;
>
> But it's not in pattern, texture, normal, or fnintern (that I see)

Hello Bill

There's a definition of Noise here:
https://github.com/POV-Ray/povray/blob/master/source/core/material/noise.h#L196

In which file did you see VScale ?

BTW: Have you ever tried Midnight Commander ?
I find it very easy to use when searching through a lot of files.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Location of Noise() and VScale() in source? [2544 days 17 hours and 13 minutes ago]

Fri, 19 Apr 2019 23:45:00 GMT

I was just poking around in the turbulence code, and it references

Noise ()
and
VScale ()

I was wondering where those were located.

I tried

find -type f -exec grep -H ' Noise(' {} \;

But it's not in pattern, texture, normal, or fnintern (that I see)

[clipka] Broken Mac OS X build - help appreciated [2611 days 21 hours and 31 minutes ago]

Mon, 11 Feb 2019 19:26:47 GMT

Hi folks,

Commit 5219e71c does not compile on Mac OS X, and I'm not really sure why.

The build runs into a compile error in `base/image/jpeg.cpp`, in which 
`TRUE` is passed to a JPEG lib function parameter of type `boolean`.

Now by some quirks of the include hierarchy, a header file 
`mach/boolean.h` is pulled in (apparently _after_ `<jpeglib.h>`), and 
defines `TRUE` as `1`, while JPEGlib apparently wants it to be... well, 
something else apparently, fitting the type `boolean` - whatever that 
might end up being defined as.

I'll be pushing a workaround any moment now, but I'd really like to know 
what's going on there. If someone with better access to a Mac system (or 
maybe just a different pair of Mk1 eyeballs) could have a look into 
this, I'd greatly appreciate it.

[eticre] Re: povmodeler [2667 days 18 hours and 53 minutes ago]

Mon, 17 Dec 2018 22:05:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "eticre" <eti### [at] tinit> wrote:
> > If anyone need my last kpovmodeler code for kf5/plasma5/qt5 I can upload it in
> > git
>
> I think it'd be nice if you kept posting updated code, I for one will try and
> chekc the next version(s).
>
>
> regards, jr.


https://github.com/eticre/kpovmodeler.git

git repo with kde dependences

[jr] Re: povmodeler [2675 days 3 hours and 38 minutes ago]

Mon, 10 Dec 2018 13:20:00 GMT

hi,

"eticre" <eti### [at] tinit> wrote:
> If anyone need my last kpovmodeler code for kf5/plasma5/qt5 I can upload it in
> git

I think it'd be nice if you kept posting updated code, I for one will try and
chekc the next version(s).


regards, jr.

[eticre] Re: povmodeler [2679 days 18 hours and 28 minutes ago]

Wed, 5 Dec 2018 22:30:01 GMT

dick balaska <dic### [at] buckosoftcom> wrote:
> On 12/3/18 5:19 PM, eticre wrote:
> > hello everyone
>
> I got it built and running.  I can't get it to look anything like this
>
http://web.archive.org/web/20120204081159/http://www.kpovmodeler.org/index.php?option=com_content&view=category&layou
t=blog&id=2&Itemid=5&lang=en
>
> but the treeview looks cool, as long as I don't touch show/hide.
>
>
> --
> dik
> Rendered 1024 of 921600 pixels (0%)

in the image the "Insert" menu is replicated in a toolbar and all povray object
are visible
in my personal this is only waste space

however I am reprogramming the toolbar in qt

[eticre] Re: povmodeler [2679 days 18 hours and 38 minutes ago]

Wed, 5 Dec 2018 22:20:00 GMT

"Ton" <ton### [at] gmailcom> wrote:
> "eticre" <eti### [at] tinit> wrote:
> > ops!
> > ..kpm files in kpovmodeler are archive compressed
> >
> > git repo is now updatete with .kpm plain text file
> >
> > I removed karchive from project but qt5 has nothing like it
>
> Hi eticre,
>
> congratulations on porting kpovmodeler to QT5. I tried, but my knowledge was not
> enough to get it all going.
> karchive is part of KDE Frameworks 5, and should be available
> (https://api.kde.org/frameworks/karchive/html/index.html).
>
> In my compiled version of povmodeler, after fixing the opengl library issue, I
> don't see the statusbar.
>
> Cheers
> Ton.

I removed all kde deps from povmodeler, now the only dependencies are Qt
missed (K)statusbar is under investigation

If anyone need my last kpovmodeler code for kf5/plasma5/qt5 I can upload it in
git

[eticre] Re: povmodeler [2679 days 19 hours and 8 minutes ago]

Wed, 5 Dec 2018 21:50:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "eticre" <eti### [at] tinit> wrote:
> > ops!
> > ..kpm files in kpovmodeler are archive compressed
>
> thanks, that helped.  "gzip".
>
> not a problem but curious: in preferences, the combo box (under povray
> documentation) only provides for POV-Ray version 3.1 or 3.5 selection.  why
> those two versions?  and, what does it select?
>
>
> regards, jr.

ignore it should be removed
is an obsolete class created for compatibility
now I inserted RAW containing "#version 3.7;" in first position of the scene

[dick balaska] Re: povmodeler [2680 days 12 hours and 25 minutes ago]

Wed, 5 Dec 2018 04:32:57 GMT

On 12/3/18 5:19 PM, eticre wrote:
> hello everyone

I got it built and running.  I can't get it to look anything like this
http://web.archive.org/web/20120204081159/http://www.kpovmodeler.org/index.php?option=com_content&view=category&layout=blog&id=2&Itemid=5&lang=en

but the treeview looks cool, as long as I don't touch show/hide.


-- 
dik
Rendered 1024 of 921600 pixels (0%)

[jr] Re: povmodeler [2680 days 15 hours and 43 minutes ago]

Wed, 5 Dec 2018 01:15:01 GMT

hi,

"eticre" <eti### [at] tinit> wrote:
> ops!
> ..kpm files in kpovmodeler are archive compressed

thanks, that helped.  "gzip".

not a problem but curious: in preferences, the combo box (under povray
documentation) only provides for POV-Ray version 3.1 or 3.5 selection.  why
those two versions?  and, what does it select?

regards, jr.

[Ton] Re: povmodeler [2680 days 15 hours and 53 minutes ago]

Wed, 5 Dec 2018 01:05:00 GMT

"eticre" <eti### [at] tinit> wrote:
> ops!
> ..kpm files in kpovmodeler are archive compressed
>
> git repo is now updatete with .kpm plain text file
>
> I removed karchive from project but qt5 has nothing like it

Hi eticre,

congratulations on porting kpovmodeler to QT5. I tried, but my knowledge was not
enough to get it all going.
karchive is part of KDE Frameworks 5, and should be available
(https://api.kde.org/frameworks/karchive/html/index.html).

In my compiled version of povmodeler, after fixing the opengl library issue, I
don't see the statusbar.

Cheers
Ton.

[eticre] Re: povmodeler [2680 days 19 hours and 58 minutes ago]

Tue, 4 Dec 2018 21:00:01 GMT

ops!
..kpm files in kpovmodeler are archive compressed

git repo is now updatete with .kpm plain text file

I removed karchive from project but qt5 has nothing like it

[jr] Re: povmodeler [2681 days and 28 minutes ago]

Tue, 4 Dec 2018 16:30:05 GMT

"jr" <cre### [at] gmailcom> wrote:
> I get an error due, it seems, to the name of one library.

solved, in a hack-ish way.  there is a file 'link.txt' which controls the
linking, and removing the redundant '-lOPenGL' switch does it.

running into other problems though, one of which is opening one of the example
scenes ("media1.kpm") results in an error dialog "Could not load the document's
data".  the other is .. copious, mostly warnings, output during execution:

jr@crow:6:povmodeler$ ./povmodeler
QCommandLineParser: option not defined: "-dri"
QObject::connect: No such signal QMenu::activated(int)
Serialization method for  "Light"  shadows old implementation
Serialization method for  "GlobalSettings"  shadows old implementation
Serialization method for  "Interior"  shadows old implementation
Serialization method for  "Pattern"  shadows old implementation
Serialization method for  "Normal"  shadows old implementation
Serialization method for  "Warp"  shadows old implementation
Serialization method for  "Finish"  shadows old implementation
Serialization method for  "Media"  shadows old implementation
Serialization method for  "GraphicalObject"  shadows old implementation
Serialization method for  "Pigment"  shadows old implementation
Serialization method for  "Texture"  shadows old implementation
Serialization method for  "BicubicPatch"  shadows old implementation
Serialization method for  "Triangle"  shadows old implementation

QObject::connect: No such signal QWidgetAction::valueChanged(int)
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
PMSPhere::setUSteps: U must be greater than 1
PMSphere::setVSteps: V must be greater than 3
PMCylinder::setSteps: S must be greater than 3
PMCone::setSteps: S must be greater than 4
PMTorus::setUSteps: U must be greater than 1
PMTorus::setVSteps: V must be greater than 3
PMLathe::setSSteps: S must be greater than 0
PMLathe::setRSteps: R must be greater than 3
PMSurfaceOfRevolution::setSSteps: S must be greater than 0
PMSurfaceOfRevolution::setRSteps: R must be greater than 3
PMPrism::setSSteps: S must be greater than 0
PMPlane::setPlaneSize: Size must be greater than 0.1
PMDisc::setSteps: S must be greater than 3
PMBlobSphere::setUSteps: U must be greater than 1
PMBlobSphere::setVSteps: V must be greater than 3
PMBlobCylinder::setUSteps: U must be greater than 1
PMBlobCylinder::setVSteps: V must be greater than 3
PMSuperquadricEllipsoid::setUSteps: U must be greater than 1
PMSuperquadricEllipsoid::setVSteps: V must be greater than 1
PMSphereSweep::setRSteps: R must be greater than 3
PMSphereSweep::setSSteps: S must be greater than 0
PMHeightField::setVariance: V must be less than 52 & greater than 0

Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
Asking for share context for widget that does not have a window handle
QOpenGLWidget: Cannot be used without a context shared with the toplevel.
pmshell desctructor
pmshell01
dockmainwindow desctructor


that's linked against qt5.

regards, jr.

[jr] Re: povmodeler [2681 days 5 hours and 13 minutes ago]

Tue, 4 Dec 2018 11:45:00 GMT

hi,

"eticre" <eti### [at] tinit> wrote:
> hello everyone
>
> I just finished a review of kpovmodeler
> I removed all kde dependency
> if anyone wants test...

first off, thank you.  a modelling s/ware is high on my wish list.

> git clone https://github.com/eticre/povmodeler.git
> cd povmodeler
> mkdir build
> cd build
> cmake ../
> make -j4
> make install
> ~/.local/share/povmodeler/povmodeler
>
> tested on archlinux
>
> all files installed are in ~/.local/share/povmodeler

I get an error due, it seems, to the name of one library.
since I don't know CMake well enough, I've no idea why it
finds the correct library (libGL) but then tries to link
against a different one (libOpenGL).  any ideas?

jr@crow:23:b$ cmake ../povmodeler/
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so -
found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib64/libX11.so
-- Found OpenGL: /usr/lib64/libGL.so
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.5.5")
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/B/b
jr@crow:24:b$ make -j2
  ...
[100%] Built target povmodelerpart
[100%] Building CXX object CMakeFiles/povmodeler.dir/povmodeler_automoc.cpp.o
Linking CXX executable povmodeler
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../x86_64-slackware-linux/bin/ld:
cannot find -lOpenGL
collect2: error: ld returned 1 exit status
make[2]: *** [povmodeler] Error 1
make[1]: *** [CMakeFiles/povmodeler.dir/all] Error 2
make: *** [all] Error 2


regards, jr.

[eticre] povmodeler [2681 days 18 hours and 33 minutes ago]

Mon, 3 Dec 2018 22:25:00 GMT

hello everyone

I just finished a review of kpovmodeler
I removed all kde dependency
if anyone wants test...


git clone https://github.com/eticre/povmodeler.git
cd povmodeler
mkdir build
cd build
cmake ../
make -j4
make install
~/.local/share/povmodeler/povmodeler

tested on archlinux

all files installed are in ~/.local/share/povmodeler

[dick balaska] Re: qtpovray and debian [2821 days 20 hours and 33 minutes ago]

Mon, 16 Jul 2018 20:25:09 GMT

On 07/16/2018 08:57 AM, clipka wrote:

> while the master branch was bumped to the next version number, v3.8.1.

That makes sense.  I retract 'burp'.

(I had assumed [1] you changed 3.7.1 to 3.8.0 and changed the 7 to 8 and
forgot to change 1 to 0.)


[1] When you assume ...

-- 
dik
Rendered 328976 of 330000 (99%)

[clipka] Re: qtpovray and debian [2822 days 2 hours and 28 minutes ago]

Mon, 16 Jul 2018 14:29:35 GMT

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

"Most" is the keyword here.

> I just merged autobuild/alpha_v380.  In source/base/version.h I picked
> up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
> from 2017 to 2018.
> But, I still have
> #define POV_RAY_PATCHLEVEL_INT      1
> instead of
> #define POV_RAY_PATCHLEVEL_INT      0
> which is in the merged-from file.
> 
> Why?  I have not altered this, and if I had, I should get a conflict.
> If makes me nervous for whatever other files I may not have picked up
> changes on.

Unfortunately, v3.8.0-alpha.9606898 was built just /before/ the merge of
`master` and `release/v3.8.0`.

This means your version number details are determined as follows:

- The _common base_ is the last common ancestor (including merges) of
`qtpovray` and `autobuild/alpha_v380`. That would be commit bb85b4fd
dated 2017-11-18, then on the `release/v3.8.0` branch. On that commit,
the version number details were as follows:

    #define POV_RAY_MAJOR_VERSION_INT   3
    #define POV_RAY_MINOR_VERSION_INT   8
    #define POV_RAY_REVISION_INT        0
    #define POV_RAY_PATCHLEVEL_INT      0
    #define POV_RAY_PRERELEASE          "alpha"

- One line of inheritance would be via the `master` branch and then
`qtpovray`, starting with the merge commit b3038c26 dated 2017-12-03.
While this commit leaves the version number unchanged /on the master
branch/, the commit /does/ constitute a version number change with
respect to the _common base_, changing the following:

    #define POV_RAY_REVISION_INT        1

- The second line of inheritance would be via `release/v3.8.0` and then
`autobuild/alpha_v380`. The only version number changes with respect to
the _common base_ in this line of inheritance are changes of the
prerelease ID, with the last such change being the following:

    #define POV_RAY_PRERELEASE          "alpha.9606898"

So you have one line of inheritance saying POV_RAY_REVISION_INT needs to
be changed to 1, and another line of inheritance saying
POV_RAY_PRERELEASE needs to be changed from "alpha" to "alpha.9606898".

Since the changes seem to be independent, no conflict is raised, leaving
you with version number v3.8.1-alpha.9606898.

[clipka] Re: qtpovray and debian [2822 days 4 hours and 1 minute ago]

Mon, 16 Jul 2018 12:57:02 GMT

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

For the records, that was not a burp. Here's what had happened:

- What is now v3.8.0 (currently in alpha phase) was originally slated to
be released as v3.7.1, and as such had already reached beta phase (and,
for a few days, even RC phase) before being rebranded as v3.8.0.

- Upon reaching beta phase, v3.7.1 was branched off `master` so that
finalization of that version could happen in a separate branch
(`release/v3.7.1`), while the master branch could continue to be used
for adding new features. At that point, the master branch was bumped to
version number v3.7.2-alpha.

- When it was decided that v3.7.1 would be too different from v3.7.0, it
was re-branded v3.8.0.

- While v3.8.0 was put back into alpha stage, it was originally expected
that the version would quickly fast-forward to RC phase again. It was
therefore left in its own branch (though now renamed `release/v3.8.0`),
while the master branch was bumped to the next version number, v3.8.1.

- When it became obvious that v3.8.0-beta wasn't going to be just a few
days ahead, all the changes in the master branch (i.e. changes
originally slated for a later version) were also merged into v3.8.0, and
that version moved back into the master branch. (Technically this was
done by simply merging v3.8.0 into the master branch.)

[dick balaska] Re: qtpovray and debian [2822 days 8 hours and 13 minutes ago]

Mon, 16 Jul 2018 08:44:24 GMT

I don't get git.
My last merge of povray was from master on 12/17/17.
At the time, source/base/version.h was reporting povray as version
3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"

I picked up that version number (and didn't really care).

In my head, I noticed a discrepancy when clipka suggested I call mine
v3.80.0 (why not 3.81.0 ?).

Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
most of the branches.

I just merged autobuild/alpha_v380.  In source/base/version.h I picked
up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
from 2017 to 2018.
But, I still have
#define POV_RAY_PATCHLEVEL_INT      1
instead of
#define POV_RAY_PATCHLEVEL_INT      0
which is in the merged-from file.

Why?  I have not altered this, and if I had, I should get a conflict.
If makes me nervous for whatever other files I may not have picked up
changes on.

https://github.com/dickbalaska/qtpovray/commit/f0eb4228ecfe624e905fe04367a73d3cc514f8fa#diff-456b041bdd8c9f06ec0514302ebba61b
( https://tinyurl.com/y7t5hh8x )
-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2838 days 23 hours and 38 minutes ago]

Fri, 29 Jun 2018 17:20:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> >> I think I can add the 'view' menu.  Currently, it is Qt magic.
> > I tried switching all except 'main' off, then there seems to be no "docking
> > border"s.
> Hmm, yes I see. You're kind of screwed, eh?

didn't you mean "screwy"?  :-)

> The toolbar has a grabber on the left side. Try to right-click that, or
> someplace on the toolbar that's not a button.

either way, thanks, easy -- once one knows.

> >>> [19:51:01.141] WARN QXcbConnection: XCB error: ...
> >> This one is interesting.  Um, what it means is um ...
> >> I would guess maybe it's trying to draw to one of the windows you closed
> >> (although Qt should be filtering that).
> > I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> > existing .pws files).
> Since this is something between Qt and X11, it would be helpful to know
> when this error^H^H warning occurred.  My X log just has a ton of
> "monitor on, monitor off".

I understand.  will try and pay closer attention when I'll use/play with
'qtpovray'.

> > soon you'll be pulling your hair out because I'll be nitpicking and flood you
> > with "feature requests".  :-)
> >
> > speaking of which, the name of the current workspace (file) would be good to
> > have in the titlebar, or somewhere prominent.
> >
> > (see, it's already started..  :-))
>
> I guess I should open the github bug thingy.

I'll make it worth your while: whether checked or not, "large icons" is,
apparently, all that is on offer.  ;-)


regards, jr.

[dick balaska] Re: qtpovray and debian [2839 days 17 hours and 43 minutes ago]

Thu, 28 Jun 2018 23:15:11 GMT

On 06/28/2018 05:50 PM, jr wrote:
> hi,

>>
>> I think I can add the 'view' menu.  Currently, it is Qt magic.
>> Right-click on one of the docking borders. That is, the "Resources"
>> header or the "Consoles" header. It will give you a list of available
>> windows to turn on and off.
> 
> I tried switching all except 'main' off, then there seems to be no "docking
> border"s.
> 

Hmm, yes I see. You're kind of screwed, eh?

The toolbar has a grabber on the left side. Try to right-click that, or 
someplace on the toolbar that's not a button.


> 
>>> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
>>> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>>
>> This one is interesting.  Um, what it means is um ...
>> I would guess maybe it's trying to draw to one of the windows you closed
>> (although Qt should be filtering that).
> 
> I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> existing .pws files).

Since this is something between Qt and X11, it would be helpful to know 
when this error^H^H warning occurred.  My X log just has a ton of 
"monitor on, monitor off".


> 
> soon you'll be pulling your hair out because I'll be nitpicking and flood you
> with "feature requests".  :-)
> 
> speaking of which, the name of the current workspace (file) would be good to
> have in the titlebar, or somewhere prominent.
> 
> (see, it's already started..  :-))

I guess I should open the github bug thingy.

> 
> 
> regards, jr.
> 
> 


-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2839 days 19 hours and 3 minutes ago]

Thu, 28 Jun 2018 21:55:00 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > how does one re-open the render view + Consoles widgets after they have been
> > closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.
>
> I think I can add the 'view' menu.  Currently, it is Qt magic.
> Right-click on one of the docking borders. That is, the "Resources"
> header or the "Consoles" header. It will give you a list of available
> windows to turn on and off.

I tried switching all except 'main' off, then there seems to be no "docking
border"s.

> > btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> If you didn't install them, that's pretty much what you get.  I am going
> to dim those menu entries if they don't exist.

yes, or (as many do) a simple "ok" type dialog with message?

> And add a bit in the
> config dialog so you can point to wherever those directories live on
> your system.

sounds good.  more flexibility.

>  I just added those two menus last night, having discovered
> the pretty awesome distribution/scenes directory (open that in firefox).

I have those too, did them for povray 3.7.

> > also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> > per invocation.
> >
> > [19:23:28.805] WARN
> > Unhandled PrintStatusChanged
> >   ((null):0)
>
> This is debug foo. I should remove it from production.  Basically povray
> is telling me something I'm ignoring.

ok.

> > [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> > resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>
> This one is interesting.  Um, what it means is um ...
> I would guess maybe it's trying to draw to one of the windows you closed
> (although Qt should be filtering that).

I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
existing .pws files).

> > would like to read the tutorial etc, but, probably because I'm a bit dense at
> > times, the "compass" feature does not work for me, which "next" button?
> Last night I copied
> http://www.buckosoft.com/qtpov/
> to
> http://www.buckosoft.com/qtpovray/
> and didn't fix the database driven navigation.  (I needed the url for
> the debian package.) Use the first one and ignore the bits about a
> separate websockets executable, and everywhere else read "qtpovray"
> where it says "qtpov".
> I am going to rework that so it can be included with the package.

cool.

> Thanks for trying it out!

soon you'll be pulling your hair out because I'll be nitpicking and flood you
with "feature requests".  :-)

speaking of which, the name of the current workspace (file) would be good to
have in the titlebar, or somewhere prominent.

(see, it's already started..  :-))


regards, jr.

[dick balaska] Re: qtpovray and debian [2839 days 20 hours and 37 minutes ago]

Thu, 28 Jun 2018 20:21:00 GMT

On 06/28/2018 01:54 PM, jr wrote:
> hi,

> 
> will do.  how does qtpovray invoke povray?  is the name hardwired?  I have only
> executables named 'povrayNN*', a symlink would be not as convenient for my
> setup, the ("dead") .ini file option looks so much better.  would it be much
> work to "resurrect" it?

povray is built into qtpovray.  There is no need for a separate 
executable.  A symlink would be of no value because there is nothing to 
point to. ;)



-- 
dik
Rendered 328976 of 330000 (99%)

[dick balaska] Re: qtpovray and debian [2839 days 20 hours and 39 minutes ago]

Thu, 28 Jun 2018 20:18:40 GMT

On 06/28/2018 03:08 PM, jr wrote:
> hi,
> 
> how does one re-open the render view + Consoles widgets after they have been
> closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

I think I can add the 'view' menu.  Currently, it is Qt magic. 
Right-click on one of the docking borders. That is, the "Resources" 
header or the "Consoles" header. It will give you a list of available 
windows to turn on and off.

> 
> btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> and I get:
> 
> xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
> xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

If you didn't install them, that's pretty much what you get.  I am going 
to dim those menu entries if they don't exist. And add a bit in the 
config dialog so you can point to wherever those directories live on 
your system.  I just added those two menus last night, having discovered 
the pretty awesome distribution/scenes directory (open that in firefox).

> 
> also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> per invocation.
> 
> [19:23:28.805] WARN
> Unhandled PrintStatusChanged
>   ((null):0)

This is debug foo. I should remove it from production.  Basically povray 
is telling me something I'm ignoring.

> 
> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

This one is interesting.  Um, what it means is um ...
I would guess maybe it's trying to draw to one of the windows you closed 
(although Qt should be filtering that).

> 
> would like to read the tutorial etc, but, probably because I'm a bit dense at
> times, the "compass" feature does not work for me, which "next" button?

Last night I copied
http://www.buckosoft.com/qtpov/
to
http://www.buckosoft.com/qtpovray/

and didn't fix the database driven navigation.  (I needed the url for 
the debian package.) Use the first one and ignore the bits about a 
separate websockets executable, and everywhere else read "qtpovray" 
where it says "qtpov".
I am going to rework that so it can be included with the package.

> 
> 
> regards, jr.

Thanks for trying it out!

-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2839 days 21 hours and 48 minutes ago]

Thu, 28 Jun 2018 19:10:06 GMT

hi,

how does one re-open the render view + Consoles widgets after they have been
closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

happened because I rendered a static scene, clicked that editor tab shut, opened
another scene, then the associated ini, chose that for rendering.  however, the
view of the previous image remained, so I clicked it shut - only not to find a
way to reopen it.

btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
and I get:

xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
per invocation.

[19:23:28.805] WARN
Unhandled PrintStatusChanged
 ((null):0)

[19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

would like to read the tutorial etc, but, probably because I'm a bit dense at
times, the "compass" feature does not work for me, which "next" button?


regards, jr.

[jr] Re: qtpovray and debian [2839 days 22 hours and 28 minutes ago]

Thu, 28 Jun 2018 18:30:05 GMT

"jr" <cre### [at] gmailcom> wrote:
> > Try right-click on the filename in the Resources view and "Select for
> > Render"
> will do.

success.  :-)

btw, is there a legit way to 'wget' the documentation part of your website?
convenience..

cheers.


regards, jr.

[jr] Re: qtpovray and debian [2839 days 22 hours and 58 minutes ago]

Thu, 28 Jun 2018 18:00:05 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> Although you may be looking at the file in the editor, you haven't
> selected it for rendering. (No input file provided).
> Try right-click on the filename in the Resources view and "Select for
> Render"

will do.  how does qtpovray invoke povray?  is the name hardwired?  I have only
executables named 'povrayNN*', a symlink would be not as convenient for my
setup, the ("dead") .ini file option looks so much better.  would it be much
work to "resurrect" it?

> Weird my tutorial fails to mention this step.
> http://www.buckosoft.com/qtpovray/tutorial/
>
> I am concerned in your report that the "No input file provided" message
> did not appear in the Consoles.POV-Ray box. That's a bug.

</weak-sounding-hurrah>  :-)

> > no idea what a "PovrayInsertMenu" is, is it needed?
> Not needed, but a cool feature. It is adopted from the POV-Ray for
> Windows insert menu. Basically it is a pile of code snippets with
> preview graphics that you can insert into your SDL.
> http://www.buckosoft.com/qtpovray/insertText/

I'll look into this.  thanks.

>  > PovrayExecutable=/usr/local/bin/povray380a
> This line is dead. It is left over from the websockets edition and is
> unused.


regards ,jr.

[dick balaska] Re: qtpovray and debian [2839 days 23 hours and 27 minutes ago]

Thu, 28 Jun 2018 17:30:30 GMT

On 06/28/2018 12:39 PM, jr wrote:
> hi,

> 
>> qt/gui/qtpovray        # run the executable
> 
> ah, yes.  another problem, afraid to say..
> 
> start 'qtpovray',

Well that's progress!

> open a scene file, looks ok in editor, click the green arrow,
> and:
> 
>    chdir:  /home/jr/wip/pov/media
>    command:
> 
> appears in Consoles.POV-Ray box, and the following is appended to the Xserver's
> log:
> 
> [12:47:59.570] WARN unhandled message: command: "stream fatal " text: "No input
> file provided" ((null):0)
> [12:47:59.570] WARN ErrorExit:  "No input file provided" ((null):0)
> 
> no other, discernable activity.  [raised eyebrow emoji, if I knew it]
> 

Although you may be looking at the file in the editor, you haven't 
selected it for rendering. (No input file provided).
Try right-click on the filename in the Resources view and "Select for 
Render"

Weird my tutorial fails to mention this step.
http://www.buckosoft.com/qtpovray/tutorial/

I am concerned in your report that the "No input file provided" message 
did not appear in the Consoles.POV-Ray box. That's a bug.

> from the 'qtpov.ini':
> 
> [General]
> recentWorkspaces=/home/jr/.cache/qtpovray/b.pws
> 
> [EditorColors]
> 
> [Keys]
> 
> [Preferences]
> PovrayExecutable=/usr/local/bin/povray380a
> PovrayIncludes=/usr/local/share/povray-3.8/include
> PovrayInsertMenu=
> 
> 
> no idea what a "PovrayInsertMenu" is, is it needed?

Not needed, but a cool feature. It is adopted from the POV-Ray for 
Windows insert menu. Basically it is a pile of code snippets with 
preview graphics that you can insert into your SDL.
http://www.buckosoft.com/qtpovray/insertText/

 > PovrayExecutable=/usr/local/bin/povray380a

This line is dead. It is left over from the websockets edition and is 
unused.

-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2840 days and 18 minutes ago]

Thu, 28 Jun 2018 16:40:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > editor/codeeditor.cpp:112:8: error: â€˜class
CodeEditorâ€™ has no member > Sorry about that. I actually fixed that 
(debian defaults to an older
> "official" version of Qt) but I didn't push the changes back to github.
> Try it now.
> Also note the repo changed names.
>
> git clone https://github.com/dickbalaska/qtpovray.git
> cd qtpovray
> git checkout qtpovray
> qmake
> make -j4

thank you, both for the whole thing + the renaming.
now works as expected.

> qt/gui/qtpovray        # run the executable

ah, yes.  another problem, afraid to say..

start 'qtpovray', open a scene file, looks ok in editor, click the green arrow,
and:

  chdir:  /home/jr/wip/pov/media
  command:

appears in Consoles.POV-Ray box, and the following is appended to the Xserver's
log:

[12:47:59.570] WARN unhandled message: command: "stream fatal " text: "No input
file provided" ((null):0)
[12:47:59.570] WARN ErrorExit:  "No input file provided" ((null):0)

no other, discernable activity.  [raised eyebrow emoji, if I knew it]

from the 'qtpov.ini':

[General]
recentWorkspaces=/home/jr/.cache/qtpovray/b.pws

[EditorColors]

[Keys]

[Preferences]
PovrayExecutable=/usr/local/bin/povray380a
PovrayIncludes=/usr/local/share/povray-3.8/include
PovrayInsertMenu=


no idea what a "PovrayInsertMenu" is, is it needed?

>  >> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
>  >> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)
>  >
>  > :-)  maybe that's a subconscious .. yearning for the old days.  ;-)
>
> Yeah, I miss working for hours to get an integrated apache/php/ssl chain
> (or postfix/dovecot/ssl).  Typing "sudo apt upgrade" is too easy.

</grin>

> I stuck with slackware for so long because, loyalty, and because I
> wanted to be more intimate with those tools.  These days, I just want it
> to work. :)
>  > if you do make it 14.2 though, which most use.  apparently, 15.0 is a
>  > possibility for later this year.
> I thought of that. But my google says 14.2 uses qt-5.6.1 (or 5.7.1 or
> 5.9.5)  The main reason for the exercise would be to build with qt-4.8 .

ok.  I'll be happy to test building here should you decide to go for it


regards, jr.

[dick balaska] Re: qtpovray and debian [2840 days 19 hours and 58 minutes ago]

Wed, 27 Jun 2018 21:00:12 GMT

On 06/27/2018 01:00 PM, jr wrote:
> hi,

> editor/codeeditor.cpp:112:8: error: â€˜class
CodeEditorâ€™ has no member named
> â€˜setTabStopDistanceâ€™
>    this->setTabStopDistance(fm.width(spaces));
>          ^

Sorry about that. I actually fixed that (debian defaults to an older 
"official" version of Qt) but I didn't push the changes back to github.
https://github.com/dickbalaska/qtpovray/commit/d70eede7700cbde40cbdbd6347a4a50ef85763a2

Try it now.

Also note the repo changed names.

git clone https://github.com/dickbalaska/qtpovray.git
cd qtpovray
git checkout qtpovray
qmake
make -j4
qt/gui/qtpovray        # run the executable

 >> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
 >> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)
 >
 > :-)  maybe that's a subconscious .. yearning for the old days.  ;-)

Yeah, I miss working for hours to get an integrated apache/php/ssl chain
(or postfix/dovecot/ssl).  Typing "sudo apt upgrade" is too easy.
I stuck with slackware for so long because, loyalty, and because I 
wanted to be more intimate with those tools.  These days, I just want it 
to work. :)

 >
 > if you do make it 14.2 though, which most use.  apparently, 15.0 is a
 > possibility for later this year.
 >

I thought of that. But my google says 14.2 uses qt-5.6.1 (or 5.7.1 or 
5.9.5)  The main reason for the exercise would be to build with qt-4.8 .

-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2840 days 23 hours and 53 minutes ago]

Wed, 27 Jun 2018 17:05:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > out of interest, without gui, what are the differences to "stock" povray?
> I should be equivalent to povray-3.8.0-alpha-something. ...

ok.

> > btw, installed Qt5 but hit another snag with the qtpovray build.  ...
> Try
> $ qmake -qt=qt5 -r
> or
> $ export QT_SELECT=qt5
> $ qmake -r
> Ref:
>
https://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake

that link helped, the '--version' providing the clue.  /usr/bin/qmake is a
symbolic link.  :-) installation of Qt5 left the existing link alone, easily
remedied.  and leading to another problem.  sorry.

Script started on Wed 27 Jun 2018 11:33:46 BST
jr@crow:13:qtpovray$ make
cd qt/libpovray/ && ( test -e Makefile || /usr/bin/qmake
/tmp/B/qtpovray/qt/libpovray/libpovray.pro -o Makefile ) && make -f Makefile
make[1]: Entering directory `/tmp/B/qtpovray/qt/libpovray'

runs ok until:

g++ -c -pipe -O2 -march=native -mtune=native -fPIC -std=gnu++11 -Wall -W
-D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_WIDGETS_LIB
-DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../vfe -I../vfe -I../libpovray -I../platform
-isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem
/usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -I. -I.
-I/usr/lib64/qt5/mkspecs/linux-g++ -o codeeditor.o editor/codeeditor.cpp
editor/codeeditor.cpp: In member function ‘void
CodeEditor::configure(PreferenceData*)’:
editor/codeeditor.cpp:112:8: error: ‘class CodeEditor’ has no member named
‘setTabStopDistance’
  this->setTabStopDistance(fm.width(spaces));
        ^
make[1]: *** [codeeditor.o] Error 1
make[1]: Leaving directory `/tmp/B/qtpovray/qt/gui'
make: *** [sub-qt-gui-make_first-ordered] Error 2
jr@crow:14:qtpovray$

the library version is 5.7.1.


> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)

:-)  maybe that's a subconscious .. yearning for the old days.  ;-)

if you do make it 14.2 though, which most use.  apparently, 15.0 is a
possibility for later this year.


regards, jr.

[dick balaska] Re: qtpovray and debian [2841 days 16 hours and 50 minutes ago]

Wed, 27 Jun 2018 00:08:01 GMT

On 06/26/2018 05:45 PM, jr wrote:
> hi,
> 
> dick balaska <dic### [at] buckosoftcom> wrote:
>> It could be one executable, but that's some work.  (Two vfe/frontends,
>> parse a command line, don't start the Qt loop). I can easily whip of a
>> copy of the current unix povray-3.8 but built with qmake.  Plus, even if
>> I don't start the gui, it's still linked to, and will load all of that
>> unused Qt graphics baggage.
> 
> out of interest, without gui, what are the differences to "stock" povray?

I should be equivalent to povray-3.8.0-alpha-something. My last merge 
was from the release/v3.8.0 branch on 2017-12-02.
povray on unix is built with autoconf/make/g++.
qtpovray on unix is built with qmake/make/g++.
If I did my job well, it will run exactly the same.

> 
> btw, installed Qt5 but hit another snag with the qtpovray build.  apparently,
> (q)make does not pick up the QT5DIR environment variable.  when make enters the
> 'qt/gui' directory, compilation fails with "does not name a type" error(s); it's
> not using the qt5 include files (in four of the -I switches).
> 

Try
$ qmake -qt=qt5 -r
or
$ export QT_SELECT=qt5
$ qmake -r

Ref:
https://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake

BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu 
18.  I've thought about spinning up a Slackware 14.1 because of you. :)

> 
> regards, jr.
> 
> 
> 


-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2841 days 19 hours and 8 minutes ago]

Tue, 26 Jun 2018 21:50:00 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> It could be one executable, but that's some work.  (Two vfe/frontends,
> parse a command line, don't start the Qt loop). I can easily whip of a
> copy of the current unix povray-3.8 but built with qmake.  Plus, even if
> I don't start the gui, it's still linked to, and will load all of that
> unused Qt graphics baggage.

out of interest, without gui, what are the differences to "stock" povray?

btw, installed Qt5 but hit another snag with the qtpovray build.  apparently,
(q)make does not pick up the QT5DIR environment variable.  when make enters the
'qt/gui' directory, compilation fails with "does not name a type" error(s); it's
not using the qt5 include files (in four of the -I switches).

regards, jr.

[dick balaska] Re: qtpovray and debian [2842 days 20 hours ago]

Mon, 25 Jun 2018 20:57:31 GMT

> misread what you wrote.  :-(  is there a need for two executables?  can that not
> be dealt with using an option?  (some use '-interactive' to get the UI version)

It could be one executable, but that's some work.  (Two vfe/frontends, 
parse a command line, don't start the Qt loop). I can easily whip of a 
copy of the current unix povray-3.8 but built with qmake.  Plus, even if 
I don't start the gui, it's still linked to, and will load all of that 
unused Qt graphics baggage.

-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2843 days 6 hours and 43 minutes ago]

Mon, 25 Jun 2018 10:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> > 3) I want to release a shell version of qtpovray, comparable to original
> > flavor povray, but povray 3.8-beta and built with qmake.  I need this
> > for my renderfarm. But, what to call it?  I'm leaning towards qtpovrayc.
>
> assuming that's a typo and you meant 'qtpovrayrc', fits in with conventions.

misread what you wrote.  :-(  is there a need for two executables?  can that not
be dealt with using an option?  (some use '-interactive' to get the UI version)

regards, jr.

[jr] Re: qtpovray and debian [2843 days 6 hours and 53 minutes ago]

Mon, 25 Jun 2018 10:05:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> I am working on two packages
> qtpovray-3.80.0
> qtpovray-includes-3.80.0
>
> 1) qtpovray-includes contains include  and Insert Menu. It should
> probably contain the help too.
> I am torn between just the one "architecture independent" package which
> contains everything, or should I split that up into multiple packages.
> Or, stay with one package and call it qtpovray-extra

speaking as a potential end user, a single archive is much nicer.  :-)

> 2) I'm not happy with the version number (3.80.0) because I have
> /usr/share/povray-3.7
> and
> /usr/share/qtpovray-3.80
> I get it, but I don't like the way it implies qtpovray is 73 minors
> beyond povray.  Is is more, or less, confusing to have qtpovray-3.80.0
> reference /usr/share/qtpovray-3.8 ?

both would be "confusing" imo.  this is the first release of qtpovray, so why
not "qtpovray-1.0.0"?  I'd expect the documentation (NEWS, README, INSTALL) to
tell me "external dependencies".

> 3) I want to release a shell version of qtpovray, comparable to original
> flavor povray, but povray 3.8-beta and built with qmake.  I need this
> for my renderfarm. But, what to call it?  I'm leaning towards qtpovrayc.

assuming that's a typo and you meant 'qtpovrayrc', fits in with conventions.

$0.02  :-)


regards, jr.

[dick balaska] Re: qtpovray and debian [2843 days 8 hours and 6 minutes ago]

Mon, 25 Jun 2018 08:51:20 GMT

I am working on two packages
qtpovray-3.80.0
qtpovray-includes-3.80.0

1) qtpovray-includes contains include  and Insert Menu. It should 
probably contain the help too.
I am torn between just the one "architecture independent" package which 
contains everything, or should I split that up into multiple packages.
Or, stay with one package and call it qtpovray-extra

2) I'm not happy with the version number (3.80.0) because I have
/usr/share/povray-3.7
and
/usr/share/qtpovray-3.80

I get it, but I don't like the way it implies qtpovray is 73 minors 
beyond povray.  Is is more, or less, confusing to have qtpovray-3.80.0 
reference /usr/share/qtpovray-3.8 ?

3) I want to release a shell version of qtpovray, comparable to original 
flavor povray, but povray 3.8-beta and built with qmake.  I need this 
for my renderfarm. But, what to call it?  I'm leaning towards qtpovrayc.


-- 
dik
Rendered 328976 of 330000 (99%)

[dick balaska] Re: qtpovray and debian [2845 days 15 hours and 45 minutes ago]

Sat, 23 Jun 2018 01:12:46 GMT

On 06/22/2018 07:50 PM, jr wrote:
> hi,

 >> The correct magic words are
 >> CONFIG += c++11
 >>
 >> in each of the .pro files.
 >
 > ah, thank you for that.  qmake documentation is not installed on my 
machine.
 >

No loss there.  There are hundreds of magic words in qmake and the doc 
only mentions the bare basics.  Everything else is google to find out 
how someone else solved the problem.

My current quest is
      make install
or
      install {
         foo
      }
in a .pro file.  This gets 3 sentences in the doc. There is a wee bit 
more to it than that.

>>> spot on.  adding that option allows the process to progress until make enters
>>> the 'qt/gui' directory, when compilation fails with missing headers (eg
>>> QtWidgets).
>>

>>
>> I don't think qtpovray will build with Qt-4.8.
> 
> correct, it's missing all the frontend stuff it seems.  (unless my memory is
> totally off, the library is organised substantially different from the 3.0
> version I upgraded to all these years ago)
> 

You're probably not missing stuff.  Qt is all about the platform 
independent frontend.

#include <QtWidgets>
is just a shortcut instead of including the 40 or so most common objects 
individually.  I guess that is a Qt-5-ism.
(You could delete that line and then walk through the individual 
undefined object errors. ;) )

Hmm, Now I wonder if qtpovray will build with Qt-4.8.
Certainly the websockets I was using is Qt-5, but that's not in this 
edition.  I'll have to give it a try.

-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2845 days 17 hours and 3 minutes ago]

Fri, 22 Jun 2018 23:55:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> >> clipka <ano### [at] anonymousorg> wrote:
> >>> ... you need to smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command
line. ...
> > spot on.  adding that option allows the process to progress until make enters
> > the 'qt/gui' directory, when compilation fails with missing headers (eg
> > QtWidgets).
>
> The correct magic words are
> CONFIG += c++11
>
> in each of the .pro files.

ah, thank you for that.  qmake documentation is not installed on my machine.

> > I'll need to think whether I really want to upgrade (from 4.8.7) to 5.11, I
>
> I don't think qtpovray will build with Qt-4.8.

correct, it's missing all the frontend stuff it seems.  (unless my memory is
totally off, the library is organised substantially different from the 3.0
version I upgraded to all these years ago)

> > remember it (building from source) being a seriously lengthy affair in 2010 or
> > so.
> which is why I finally switched from slackware to ubuntu.  Upgrading
> apache and tomcat and php just became more tedious than I wanted.

yes, the java stuff always needed .. that bit extra.

if I do find the source, I likely will upgrade[*], it's just .. an unwelcome
addition on the ever-increasing todo list.

[*] I really am quite curious now to see 'qtpovray' live.

> > in addition, I have not even found the source archive on the qt-project.org
> > website yet, only link(s) to online installers.  </sigh>
> On 06/22/2018 12:12 PM, jr wrote:
>  > btw, replying to clipka you wrote: "99% of packages don't do symlinks."
>  > the Slackware 'makepkg' does, just like .. "the big boys".:-)
> Yes.  If you want to see symlink hell try RedHat.  Everything is
> minimally a symlink to a symlink. Everything; even the files in /etc

:-)  cannot be avoided though, if only for shared lib names.  'makepkg' is
reasonably smart.  it looks for existing symlinks in the compiled and built
s/ware, and generates a shell script which re-creates the links at the end of
the install.

regards, jr.

[dick balaska] Re: qtpovray and debian [2845 days 18 hours and 2 minutes ago]

Fri, 22 Jun 2018 22:55:57 GMT

On 06/22/2018 06:30 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>>> g++ ...
>>> ... you need to smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command
line. ...
> 
> spot on.  adding that option allows the process to progress until make enters
> the 'qt/gui' directory, when compilation fails with missing headers (eg
> QtWidgets).

The correct magic words are
CONFIG += c++11

in each of the .pro files.

> 
> I'll need to think whether I really want to upgrade (from 4.8.7) to 5.11, I

I don't think qtpovray will build with Qt-4.8.

> remember it (building from source) being a seriously lengthy affair in 2010 or
> so.  

which is why I finally switched from slackware to ubuntu.  Upgrading 
apache and tomcat and php just became more tedious than I wanted.

> in addition, I have not even found the source archive on the qt-project.org
> website yet, only link(s) to online installers.  </sigh>


On 06/22/2018 12:12 PM, jr wrote:
 > btw, replying to clipka you wrote: "99% of packages don't do symlinks."
 >
 > the Slackware 'makepkg' does, just like .. "the big boys".:-)


Yes.  If you want to see symlink hell try RedHat.  Everything is 
minimally a symlink to a symlink. Everything; even the files in /etc
-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2845 days 18 hours and 23 minutes ago]

Fri, 22 Jun 2018 22:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > > g++ ...
> > ... you need to smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command
line. ...

spot on.  adding that option allows the process to progress until make enters
the 'qt/gui' directory, when compilation fails with missing headers (eg
QtWidgets).

I'll need to think whether I really want to upgrade (from 4.8.7) to 5.11, I
remember it (building from source) being a seriously lengthy affair in 2010 or
so.  in addition, I have not even found the source archive on the qt-project.org
website yet, only link(s) to online installers.  </sigh>

regards, jr.

[jr] Re: qtpovray and debian [2845 days 21 hours and 28 minutes ago]

Fri, 22 Jun 2018 19:30:01 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> > g++ ...
>
> Presuming that you have g++ 4.8.1 or later at your disposal, you need to
> smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command line. The
> CPPFLAGS environment variable might do the trick.

I do, and I will try this later on.  thank you.

> The setting is required for all g++ versions prior to 6.1.
>
> > I know you're only concerned with Ubuntu, but thought you'd like to know.
>
> From what I understand, Dick is only concerned with Debian, not Ubuntu ;)

ouch, my bad.


regards, jr.

[clipka] Re: qtpovray and debian [2845 days 22 hours and 1 minute ago]

Fri, 22 Jun 2018 18:56:32 GMT

Am 22.06.2018 um 17:12 schrieb jr:

> g++ -c -pipe -O2 -w -fPIC -D_REENTRANT -DQT_DEPRECATED_WARNINGS
> -DOPENEXR_MISSING -DBUILD_ARCH="x86_64" -DTRY_OPTIMIZED_NOISE -DBUILD_X86
> -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++ -I.
> -I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -I../../source
> -I../../platform/unix -I../../platform/x86 -I../../unix/povconfig -I../../vfe
> -I. -o tmp/QP/povray/source/backend/bounding/boundingtask.o
> ...../../source/backend/bounding/boundingtask.cpp
> In file included from ../../source/backend/frame.h:57:0,
>                  from ../../source/backend/bounding/boundingtask.cpp:42:
> ...../../source/base/configbase.h:1048:6: error: #error "This version of POV-Ray
> requires C++11, which your compiler does not seem to support."
>      #error "This version of POV-Ray requires C++11, which your compiler does
> not seem to support."
>       ^

Presuming that you have g++ 4.8.1 or later at your disposal, you need to
smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command line. The
CPPFLAGS environment variable might do the trick.

The setting is required for all g++ versions prior to 6.1.


> I know you're only concerned with Ubuntu, but thought you'd like to know.

From what I understand, Dick is only concerned with Debian, not Ubuntu ;)

[jr] Re: qtpovray and debian [2845 days 22 hours and 13 minutes ago]

Fri, 22 Jun 2018 18:45:06 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 22.06.2018 um 17:15 schrieb jr:
> > maybe a wiki page where package scripts and/or links, and "tips + tricks", for
> > various platforms can be found?
>
> If you know someone knowledgeable enough and willing to write up such a
> wiki page - sure.

I'd be happy to read up sufficient on the wiki language to add the entry for
Slackware; since all packages are built from unmodified sources, it's
essentially a link to http://www.slackbuilds.org/ where one can find the package
"ingredients" for any given os release.  the scripts are maintained and use the
3.7.0.0 source.

regards, jr.

[clipka] Re: qtpovray and debian [2845 days 22 hours and 59 minutes ago]

Fri, 22 Jun 2018 17:58:35 GMT

Am 22.06.2018 um 17:47 schrieb dick balaska:

>> I'd make sure that it is clear which version of POV-Ray it is based on.
>> For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
>> POV-Ray vX.Y.Z.
> 
> I can do that.Â  So my first would be qtpovray-3.80.1
> ja?

I'd go for 3.80.0, but the choice is up to you.


> jr whined that I didn't rename my dir root from povray to qtpovray. The
> fact that I didn't bit me in the butt here. Package qtpovray must be
> built from dir root qtpovray. Then it sees qtpovray.pro first and
> ignores any ./configure that lives there.Â  I'm going to have to rename
> my repo.

There's no rule that says your local Git repo has to have the same name
as the remote.

[clipka] Re: qtpovray and debian [2845 days 23 hours and 5 minutes ago]

Fri, 22 Jun 2018 17:52:18 GMT

Am 22.06.2018 um 17:15 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> We're not doing any Unix package maintenance, we're just providing
>> the source code,
> 
> maybe a wiki page where package scripts and/or links, and "tips + tricks", for
> various platforms can be found?

If you know someone knowledgeable enough and willing to write up such a
wiki page - sure.

[jr] Re: qtpovray and debian [2846 days and 43 minutes ago]

Fri, 22 Jun 2018 16:15:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > I know you're only concerned with Ubuntu, but thought you'd like to know.
> I have a fix for that.  ... some personalized qt config somewhere (?)
> that throws the C++11 in there.

I'll be happy (and a little curious :-)) to try.

btw, replying to clipka you wrote: "99% of packages don't do symlinks."

the Slackware 'makepkg' does, just like .. "the big boys".  :-)


regards, jr.

[dick balaska] Re: qtpovray and debian [2846 days 1 hour and 10 minutes ago]

Fri, 22 Jun 2018 15:47:46 GMT

On 06/22/2018 08:48 AM, clipka wrote:
> Am 22.06.2018 um 13:39 schrieb dick balaska:
> 
>> qtpovray_0.1
>> qtpovray-extras_0.1
>>
>> Should I call it 0.1?Â  3.8?Â  3.8.0.1?
>> qtpovray contains the executable and desktop
>> qtpovray-extras contains the glorious insert menu
> 
> I'd make sure that it is clear which version of POV-Ray it is based on.
> For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
> POV-Ray vX.Y.Z.

I can do that.  So my first would be qtpovray-3.80.1
ja?

> 
>> Maybe I should call qtpovray-extras just povray-extras?
> 
> No, you should definitely not. If it's not official POV-Ray, don't make
> it look like it is.

Well, that was my first thought. But, OTOH, there is no "official" 
povray, so screw all y'all. ;)
All praise to Andreas Beckmann <anb### [at] debianorg> (who I never heard of) 
as the debian maintainer.

(
I have read so much debian foo lately. It's too much. Then I unpacked 
the debian povray port, and it's all right there, with all the right 
magic words to make 3 packages from one set of source.  The only hard 
part was was bootstrapping qmake, for which the only documentation is a 
comment in a tutorial. "How do I use qmake instead of configure?" "Since 
version blah, it just magically works".

jr whined that I didn't rename my dir root from povray to qtpovray. The 
fact that I didn't bit me in the butt here. Package qtpovray must be 
built from dir root qtpovray. Then it sees qtpovray.pro first and 
ignores any ./configure that lives there.  I'm going to have to rename 
my repo.
)

> 
>> I want to leverage the existing povray-includes
>> which requires a release of package povray-includes_3.8.0.0
>> to pick up /usr/share/povray-3.8/includes .
>>
>> Also, to get the .ini files especially /etc/povray/3.8/povray.conf
>> I need package povray_3.8.0.0 and we're not ready for that.
> 
> In my naive understanding of Unix package management, I would suggest
> for now to release qtpovray as a collection of stand-alone packages, and
> later - once an official POV-Ray package is available - update it to
> make use of the official POV-Ray packages, modifying part of the
> qtpovray packages to do nothing more than pull in the official packages.

I will do that.
Although I would prefer if the data was in /usr/share/povray/3.[78]
I will be consistent and go with /usr/share/qtpovray-3.81 to match the 
existing style of /usr/share/povray-3.7

(Actually my personal preference is to keep it *all* together, i.e.
/opt/povray/bin
/opt/povray/etc
/opt/povray/var/include

I'm not a real fan of the debian model of sowing povray dust throughout 
the file system.  But it works for a couple hundred million (a billion?) 
installations, so it's good enough for me.
)

> 
>> I could release a qmake built package povray_3.8.0.0 with the unix shell
>> version (and the /etc/povray/3.8 files I need). But that's not my call
>> (or true focus).Â  One bleh thing about that is the executable is
>> /usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at
>> the same time, even though the data is already separated by version.
> 
> I'd say that's a thing to be addressed by whoever is the maintainer of
> the debian POV-Ray package. We're not doing any Unix package
> maintenance, we're just providing the source code, Unix build tools, and
> a bit of support. If I'm not mistaken, the configure script allows to
> specify a different binary name >
> If they're smart, the package also has a `/usr/bin/povray-3.7`
> hard-linked to the same file (or `/usr/bin/povray` soft-linked to
> `/usr/bin/povray-3.7`), so that installing another version "on top" of
> it leaves an instance of the old binary available.

99% of packages don't do symlinks.  But the big boys do; gcc, python, 
wish.  I will suggest this to the debian maintainer.

-- 
dik
Rendered 328976 of 330000 (99%)

[dick balaska] Re: qtpovray and debian [2846 days 1 hour and 37 minutes ago]

Fri, 22 Jun 2018 15:20:41 GMT

On 06/22/2018 11:12 AM, jr wrote:

> requires C++11, which your compiler does not seem to support."
>       #error "This version of POV-Ray requires C++11, which your compiler does
> not seem to support."
>        ^
> 
> 
> I know you're only concerned with Ubuntu, but thought you'd like to know.
> 

I have a fix for that.  debuild (debian package maker) gave the same 
error.  Apparently, I have some personalized qt config somewhere (?) 
that throws the C++11 in there.

-- 
dik
Rendered 328976 of 330000 (99%)

[jr] Re: qtpovray and debian [2846 days 1 hour and 38 minutes ago]

Fri, 22 Jun 2018 15:20:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> We're not doing any Unix package maintenance, we're just providing
> the source code,

maybe a wiki page where package scripts and/or links, and "tips + tricks", for
various platforms can be found?


regards, jr.

[jr] Re: qtpovray and debian [2846 days 1 hour and 43 minutes ago]

Fri, 22 Jun 2018 15:15:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> I will add 2 more [Debian pkgs]:
> qtpovray_0.1
> qtpovray-extras_0.1

fwiw, following the instructions in
http://news.povray.org/5b01fa12%241%40news.povray.org

fails to build on Slackware 14.1, a first. ;-)

jr@crow:1:povray$ make
cd qt/libpovray/ && /usr/bin/qmake /tmp/QP/povray/qt/libpovray/libpovray.pro -o
Makefile
cd qt/libpovray/ && make -f Makefile
make[1]: Entering directory `/tmp/QP/povray/qt/libpovray'
g++ -c -pipe -O2 -w -fPIC -D_REENTRANT -DQT_DEPRECATED_WARNINGS
-DOPENEXR_MISSING -DBUILD_ARCH="x86_64" -DTRY_OPTIMIZED_NOISE -DBUILD_X86
-DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++ -I.
-I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -I../../source
-I../../platform/unix -I../../platform/x86 -I../../unix/povconfig -I../../vfe
-I. -o tmp/QP/povray/source/backend/bounding/boundingtask.o
..../../source/backend/bounding/boundingtask.cpp
In file included from ../../source/backend/frame.h:57:0,
                 from ../../source/backend/bounding/boundingtask.cpp:42:
..../../source/base/configbase.h:1048:6: error: #error "This version of POV-Ray
requires C++11, which your compiler does not seem to support."
     #error "This version of POV-Ray requires C++11, which your compiler does
not seem to support."
      ^


I know you're only concerned with Ubuntu, but thought you'd like to know.


regards, jr.

[clipka] Re: qtpovray and debian [2846 days 4 hours and 10 minutes ago]

Fri, 22 Jun 2018 12:48:12 GMT

Am 22.06.2018 um 13:39 schrieb dick balaska:

> qtpovray_0.1
> qtpovray-extras_0.1
> 
> Should I call it 0.1?Â  3.8?Â  3.8.0.1?
> qtpovray contains the executable and desktop
> qtpovray-extras contains the glorious insert menu

I'd make sure that it is clear which version of POV-Ray it is based on.
For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
POV-Ray vX.Y.Z.

> Maybe I should call qtpovray-extras just povray-extras?

No, you should definitely not. If it's not official POV-Ray, don't make
it look like it is.

> I want to leverage the existing povray-includes
> which requires a release of package povray-includes_3.8.0.0
> to pick up /usr/share/povray-3.8/includes .
> 
> Also, to get the .ini files especially /etc/povray/3.8/povray.conf
> I need package povray_3.8.0.0 and we're not ready for that.

In my naive understanding of Unix package management, I would suggest
for now to release qtpovray as a collection of stand-alone packages, and
later - once an official POV-Ray package is available - update it to
make use of the official POV-Ray packages, modifying part of the
qtpovray packages to do nothing more than pull in the official packages.

> I could release a qmake built package povray_3.8.0.0 with the unix shell
> version (and the /etc/povray/3.8 files I need). But that's not my call
> (or true focus).Â  One bleh thing about that is the executable is
> /usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at
> the same time, even though the data is already separated by version.

I'd say that's a thing to be addressed by whoever is the maintainer of
the debian POV-Ray package. We're not doing any Unix package
maintenance, we're just providing the source code, Unix build tools, and
a bit of support. If I'm not mistaken, the configure script allows to
specify a different binary name.

If they're smart, the package also has a `/usr/bin/povray-3.7`
hard-linked to the same file (or `/usr/bin/povray` soft-linked to
`/usr/bin/povray-3.7`), so that installing another version "on top" of
it leaves an instance of the old binary available.


> [1] Ubuntu 18 has povray_3.7.0.4 , but I'm mostly working on Ubuntu 16
> which is povray_3.7.0.0

There's little difference there; POV-Ray v3.7.0.4 is just v3.7.0 updated
to work with the compiler and 3rd party libraries that ship with Ubuntu 18.

[dick balaska] qtpovray and debian [2846 days 5 hours and 18 minutes ago]

Fri, 22 Jun 2018 11:39:18 GMT

I was wondering if there might be a rough, pie in the sky, timeframe for 
releasing 3.8.

There are currently 3 debian packages [1]:
povray_3.7.0.0
povray-includes_3.7.0.0
povray-examples_3.7.0.0

I will add 2 more:
qtpovray_0.1
qtpovray-extras_0.1

Should I call it 0.1?  3.8?  3.8.0.1?
qtpovray contains the executable and desktop
qtpovray-extras contains the glorious insert menu

Maybe I should call qtpovray-extras just povray-extras?

I want to leverage the existing povray-includes
which requires a release of package povray-includes_3.8.0.0
to pick up /usr/share/povray-3.8/includes .

Also, to get the .ini files especially /etc/povray/3.8/povray.conf
I need package povray_3.8.0.0 and we're not ready for that.

I could release a qmake built package povray_3.8.0.0 with the unix shell 
version (and the /etc/povray/3.8 files I need). But that's not my call 
(or true focus).  One bleh thing about that is the executable is 
/usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at 
the same time, even though the data is already separated by version.

-- 
dik
Rendered 328976 of 330000 (99%)

[1] Ubuntu 18 has povray_3.7.0.4 , but I'm mostly working on Ubuntu 16 
which is povray_3.7.0.0

[clipka] Re: qtpovray [2852 days 18 hours and 36 minutes ago]

Fri, 15 Jun 2018 22:21:17 GMT

Am 15.06.2018 um 21:36 schrieb dick balaska:

> Oh, one thing I don't like, but am leaving alone,
> unix/povconfig/syspovconfig.h contains
> 
> #define
POV_CPUINFOÂ Â Â Â Â Â Â Â 
CPUInfo::GetFeatures()
> #define POV_CPUINFO_DETAILS CPUInfo::GetDetails()
> #define
POV_CPUINFO_HÂ Â Â Â Â Â 
"cpuid.h"
> 
> and then later used as
> #ifdef POV_CPUINFO_H
> #include POV_CPUINFO_H
> #endif
> 
> 1) The file cpuid.h contains the class CPUInfo. The file should be named
> cpuinfo.h to match the class.

The file `cpuid.h` just /happens/ to define only that one class these
days. The translation unit's main feature is that it provides access to
the CPUID instruction of the x86 architecture, and the name actually
predates the class. It originally started out as a collection of global
functions, which have now been bundled into aforementioned class.

Since it's not a total misnomer, it has never been renamed, in order to
more easily track the file's history.

The moniker CPUInfo, on the other hand, was chosen because other
architectures may provide CPU information in a different manner.

> 2) POV_CPUINFO_H looks a lot like the header marker
> #ifndef POVRAY_CPUID_H
> #define POVRAY_CPUID_H
> used to read includes once. It works because of the misnaming.

No, it would still work without the "misnaming", due to the header
markers having the naming convention `POVRAY_foo_H`, whereas the
compile-time config settings (mostly) have the naming convention
`POV_foo_H`.

I do concede that it does still /look/ a lot like a header marker.

> (My personal style has always been
> #ifndef _POVRAY_CPUID_H_
> #define _POVRAY_CPUID_H_
> )

That's actually very bad practice, as it is technically in violation of
the C++ standard, which reserves to "the implementation" (*) any names
beginning with an underscore followed by an uppercase letter (**).

(* i.e. the compiler and its accompanying standard include files.)

(* Also reserved are any names containing a double underscore, as well
as any names in the global namespace starting with an underscore.)


> 3) The only option for POV_CPUINFO_H is "cpuid.h" ,
> why have it at all? It *is* used as a boolean switch, but wouldn't that
> be better served by a boolean?
> I guess it was envisioned at conception as having different values for
> different architectures, but on the core editions Windows/Linux/(Mac?)
> it is only ever "cpuid.h"

Not only /was/ it envisioned as having different values for different
architectures, it still /is/. We might for instance decide to add
optimized noise implementations for ARM, where `cpuid.h` would indeed be
a misnomer.

[dick balaska] Re: qtpovray [2852 days 21 hours and 21 minutes ago]

Fri, 15 Jun 2018 19:36:26 GMT

On 06/15/2018 08:38 AM, clipka wrote:
> Am 15.06.2018 um 06:18 schrieb dick balaska:
>> Dynamic optimizations:
>>  Â  CPU detected: Intel,SSE2,AVX,AVX2,FMA3
>>  Â  Noise generator: avx2fma3-intel (hand-optimized by Intel)
>>
>> The "Noise generator" was easy, but the "CPU detected" required that I
>> rename platform/x86/cpuid.h to povcpuid.h because it conflicts with
>> /usr/lib/gcc/x86_64-linux-gnu/5/include/cpuid.h
>>
>> I don't get why, and why that wouldn't also be a problem with the
>> autoconf build.
> 
> I'd say that it's not a problem with the autoconf build because it
> shouldn't be a problem ;)
> 
> Which way round is the conflict? Is `platform/x86/cpuid.h` included
> where the other one should have been, or vice cersa? Also, in which
> source file is the offending `#include` located (and if that's not a
> POV-Ray source file, what's the exact `#include` statement)?
> 
> Does your build process invoke the compiler with a command line
> containing `-I-`? Also, what compiler are you using anyway?
> 

Dub baf.

As I was unwinding what I did to answer your questions (I deleted that 
partially composed post), I realized I straightened out the -I list in 
the same pass that I renamed cpuid.h to povcpuid.h.

So, ignore what I said, everything works as expected. :)
I'm happy with the qmake build on Linux.

My next step is to build a debian package (binaries installer)
and then get the qmake edition on Windows to build.

-------
Oh, one thing I don't like, but am leaving alone,
unix/povconfig/syspovconfig.h contains

#define POV_CPUINFO         CPUInfo::GetFeatures()
#define POV_CPUINFO_DETAILS CPUInfo::GetDetails()
#define POV_CPUINFO_H       "cpuid.h"

and then later used as
#ifdef POV_CPUINFO_H
#include POV_CPUINFO_H
#endif

1) The file cpuid.h contains the class CPUInfo. The file should be named 
cpuinfo.h to match the class.

2) POV_CPUINFO_H looks a lot like the header marker
#ifndef POVRAY_CPUID_H
#define POVRAY_CPUID_H
used to read includes once. It works because of the misnaming.
(My personal style has always been
#ifndef _POVRAY_CPUID_H_
#define _POVRAY_CPUID_H_
)

3) The only option for POV_CPUINFO_H is "cpuid.h" ,
why have it at all? It *is* used as a boolean switch, but wouldn't that 
be better served by a boolean?
I guess it was envisioned at conception as having different values for 
different architectures, but on the core editions Windows/Linux/(Mac?) 
it is only ever "cpuid.h"

I would have preferred
#ifdef HAVE_CPUINFO
#include "cpuinfo.h"
#endif

-- 
dik
Rendered 328976 of 330000 (99%)

[clipka] Re: qtpovray [2853 days 4 hours and 19 minutes ago]

Fri, 15 Jun 2018 12:38:47 GMT

Am 15.06.2018 um 06:18 schrieb dick balaska:
> Dynamic optimizations:
> Â  CPU detected: Intel,SSE2,AVX,AVX2,FMA3
> Â  Noise generator: avx2fma3-intel (hand-optimized by Intel)
> 
> The "Noise generator" was easy, but the "CPU detected" required that I
> rename platform/x86/cpuid.h to povcpuid.h because it conflicts with
> /usr/lib/gcc/x86_64-linux-gnu/5/include/cpuid.h
> 
> I don't get why, and why that wouldn't also be a problem with the
> autoconf build.

I'd say that it's not a problem with the autoconf build because it
shouldn't be a problem ;)

Which way round is the conflict? Is `platform/x86/cpuid.h` included
where the other one should have been, or vice cersa? Also, in which
source file is the offending `#include` located (and if that's not a
POV-Ray source file, what's the exact `#include` statement)?

Does your build process invoke the compiler with a command line
containing `-I-`? Also, what compiler are you using anyway?

[dick balaska] Re: qtpovray [2853 days 12 hours and 39 minutes ago]

Fri, 15 Jun 2018 04:18:21 GMT

Dynamic optimizations:
   CPU detected: Intel,SSE2,AVX,AVX2,FMA3
   Noise generator: avx2fma3-intel (hand-optimized by Intel)

The "Noise generator" was easy, but the "CPU detected" required that I 
rename platform/x86/cpuid.h to povcpuid.h because it conflicts with
/usr/lib/gcc/x86_64-linux-gnu/5/include/cpuid.h

I don't get why, and why that wouldn't also be a problem with the 
autoconf build.

-- 
dik
Rendered 328976 of 330000 (99%)

[dick balaska] Re: qtpovray [2856 days 9 hours and 50 minutes ago]

Tue, 12 Jun 2018 07:08:12 GMT

On 06/12/2018 02:21 AM, clipka wrote:

> 
> On Linux, it doesn't show when running "povray --version" (don't ask me
> why); you'll have to render a scene. (If you're re-building anyway, you
> can use "make check" for that purpose.)
> 

Ah. Don't mute the banner, thanks. :)

Yes, I see that exact message on 3.8-alpha (and on my websockets 
edition), but not on the qmake edition.

That gives me something to work from.

Thanks.

-- 
dik
Rendered 328976 of 330000 (99%)

[clipka] Re: qtpovray [2856 days 10 hours and 37 minutes ago]

Tue, 12 Jun 2018 06:21:10 GMT

Am 12.06.2018 um 00:47 schrieb dick balaska:

>> If you got the optimization framework up and running, the last portion
>> in that section will read something like this:
>>
>> Dynamic optimizations:
>> Â Â  CPU detected: Intel,SSE2,AVX,AVX2,FMA3
>> Â Â  Noise generator: avx2fma3-intel (hand-optimized by Intel)
>>
>> If the section is missing entirely, the optimized noise framework is
>> disabled entirely.
>>
>> If the section is present but reports "Noise generator: generic
>> (portable)", then the framework /per se/ is working, but the individual
>> optimizations (or at least those that would fit your CPU) are all
>> disabled.
>>
> 
> Ah poo.Â  I don't see this even with generic Linux 3.8 alpha
[...]
> 
> It is definitely being built with 3.8-alpha.
> I have seen these messages in the past, perhaps on Windows?

On Linux, it doesn't show when running "povray --version" (don't ask me
why); you'll have to render a scene. (If you're re-building anyway, you
can use "make check" for that purpose.)

[Bald Eagle] Re: qtpovray [2856 days 17 hours and 48 minutes ago]

Mon, 11 Jun 2018 23:10:01 GMT

dick balaska <dic### [at] buckosoftcom> wrote:

> Ah poo.

Apu.

http://www.drawinghowtodraw.com/stepbystepdrawinglessons/2011/08/how-to-draw-apu-from-the-simpsons-with-easy-step-by-st
ep-drawing-tutorial/

[dick balaska] Re: qtpovray [2856 days 18 hours and 10 minutes ago]

Mon, 11 Jun 2018 22:47:20 GMT

On 06/11/2018 04:18 AM, clipka wrote:
> Am 11.06.2018 um 06:38 schrieb dick balaska:
>> On 05/21/2018 04:10 AM, clipka wrote:
>>> Am 21.05.2018 um 00:43 schrieb dick balaska:

> 
> If you got the optimization framework up and running, the last portion
> in that section will read something like this:
> 
> Dynamic optimizations:
>    CPU detected: Intel,SSE2,AVX,AVX2,FMA3
>    Noise generator: avx2fma3-intel (hand-optimized by Intel)
> 
> If the section is missing entirely, the optimized noise framework is
> disabled entirely.
> 
> If the section is present but reports "Noise generator: generic
> (portable)", then the framework /per se/ is working, but the individual
> optimizations (or at least those that would fit your CPU) are all disabled.
> 

Ah poo.  I don't see this even with generic Linux 3.8 alpha
http://news.povray.org/povray.general/message/%3C5b105212%241%40news.povray.org%3E/#%3C5b105212%241%40news.povray.org%3E
( https://tinyurl.com/y6udonlu )

It is definitely being built with 3.8-alpha.
I have seen these messages in the past, perhaps on Windows?

-- 
dik
Rendered 328976 of 330000 (99%)

[clipka] Re: qtpovray [2857 days 8 hours and 40 minutes ago]

Mon, 11 Jun 2018 08:18:10 GMT

Am 11.06.2018 um 06:38 schrieb dick balaska:
> On 05/21/2018 04:10 AM, clipka wrote:
>> Am 21.05.2018 um 00:43 schrieb dick balaska:
>>
>>> I have no idea no to get qmake to do super-optimization,
> 
> Thank you for the super documentation.Â  I have libplatform.a
built.Â  I
> can't really tell if it's doing anything. I'm going to have to wire up
> the benchmark.

Wiring up the benchmark shouldn't actually be necessary, provided your
variant of POV-Ray spits out the usual version and copyright information
(see `InitInfo()` in `renderfrontend.cpp`; BTW, if your variant of
POV-Ray does /not/ spit out that information, it would be in violation
of some of the 3rd party libraries' licensing conditions.)

If you got the optimization framework up and running, the last portion
in that section will read something like this:

Dynamic optimizations:
  CPU detected: Intel,SSE2,AVX,AVX2,FMA3
  Noise generator: avx2fma3-intel (hand-optimized by Intel)

If the section is missing entirely, the optimized noise framework is
disabled entirely.

If the section is present but reports "Noise generator: generic
(portable)", then the framework /per se/ is working, but the individual
optimizations (or at least those that would fit your CPU) are all disabled.

> So, I just build those files and it magically works?Â  There's an awful
> lot of #ifdefs that look like they want some service somehow.
> 
> #ifdef MACHINE_INTRINSICS_H

Define this to the header file (if any required) that enables
machine-specific compiler intrinsics for extended instructions. E.g. for
GCC this needs to be `<x86intrin.h>`, while for MS Visual Studio this
needs to be `<intrin.h>`.

> #ifdef TRY_OPTIMIZED_NOISE_AVX
> #ifdef TRY_OPTIMIZED_NOISE_AVX2FMA3
> #ifdef TRY_OPTIMIZED_NOISE_AVXFMA4

Define these depending on which instruction set extensions the
/compiler/ supports.

These should be (un)defined globally for all source files. If for some
reason the decision to enable or disable a particular noise generator
can't be made globally, do define `TRY_OPTIMIZED_NOISE_XXX` globally,
but define `DISABLE_OPTIMIZED_NOISE_XXX` when compiling xxxnoise.cpp if
it turns out that the required instruction set extension isn't supported
after all. However, this non-global mechanism is inferior, and should be
avoided if possible.

Also, don't forget `TRY_OPTIMIZED_NOISE`, which must be defined
identically for all source files, serving as the master switch to turn
on the optimized noise framework /per se/.

Another set of macros used in conjunction with the optimized noise
framework are the `POV_CPUINFO`, `POV_CPUINFO_DETAILS` and
`POV_CPUINFO_H` macros, but these are primarily for diagnostic purpose.
If you omit them, the "Dynamic optimizations:" section will not report
"CPU detected:", but the optimized noise framework should still work fine.

[dick balaska] Re: qtpovray [2857 days 12 hours and 20 minutes ago]

Mon, 11 Jun 2018 04:38:01 GMT

On 05/21/2018 04:10 AM, clipka wrote:
> Am 21.05.2018 um 00:43 schrieb dick balaska:
> 
>> I have no idea no to get qmake to do super-optimization,

Thank you for the super documentation.  I have libplatform.a built.  I 
can't really tell if it's doing anything. I'm going to have to wire up 
the benchmark.

So, I just build those files and it magically works?  There's an awful 
lot of #ifdefs that look like they want some service somehow.

#ifdef MACHINE_INTRINSICS_H
#ifdef TRY_OPTIMIZED_NOISE_AVX
#ifdef TRY_OPTIMIZED_NOISE_AVX2FMA3
#ifdef TRY_OPTIMIZED_NOISE_AVXFMA4

-- 
dik
Rendered 328976 of 330000 (99%)

[Thorsten Froehlich] Re: Official notice - user defined function VM d... [2877 days 21 hours and 38 minutes ago]

Mon, 21 May 2018 19:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 21.05.2018 um 18:37 schrieb E-mailyvo s gmx.net:
>
> >> To the best of my knowledge there is not, and never has been, any
> >> platform-specific code that does, or ever did, rely on these structures.
> >>
> >> If I'm mistaken there, please let me know.
> >
> > If I remember well, there was a JITC but only for the Macintosh version
> > v3.6
> > JITC for the PPC (G4, G5,â€¦)
> > Maybe that was the reason for it?
>
> Sounds plausible, given that the comment was signed by Thorsten.

Yes, there was, or actually is, a JIT for PPC in the Mac version of 3.6. It gave
a 8-10 times gain in performance at the time, especially for complex functions.
The JIT is also the reason for the, at first sight, odd absolute position stack
design in the function VM ... it made the switching to JIT code easier as I
could skip implementing a full ABI compliant compiler. I. also had a prototype
for a x86 JIT at one time, but the x86 stack-based FPU is a real pain.

Thorsten

[clipka] Re: Official notice - user defined function VM d... [2877 days 22 hours and 17 minutes ago]

Mon, 21 May 2018 18:41:03 GMT

Am 21.05.2018 um 18:37 schrieb E-mailyvo s gmx.net:

>> To the best of my knowledge there is not, and never has been, any
>> platform-specific code that does, or ever did, rely on these structures.
>>
>> If I'm mistaken there, please let me know.
> 
> If I remember well, there was a JITC but only for the Macintosh version
> v3.6
> JITC for the PPC (G4, G5,â€¦)
> Maybe that was the reason for it?

Sounds plausible, given that the comment was signed by Thorsten.

> Something someone should implement again for x86? ;-)

Well, there /are/ plans (somewhere deep in one of my drawers... wait, I
think it should be here... hmm... well, never mind, I'll eventually find
them...) to migrate the user-defined functions to a portable
well-established 3rd party VM, ideally one providing JITC functionality
on the most important platforms (read: LLVM)... some day, anyway.

First I gotta get this *%&$ parser ready for public testing of the new
scanner/tokenizer, and beat out the dents I've made in the process.

[Yvo Smellenbergh] Re: Official notice - user defined function VM d... [2878 days and 17 minutes ago]

Mon, 21 May 2018 16:41:07 GMT

On 2018-05-21 16:37:54 +0000, Yvo Smellenbergh said:

> On 2018-05-21 14:16:30 +0000, clipka said:
> 
>> Hear, hear, hear!
>> 
>> I hereby give the following notice:
>> 
>> The data types `FunctionEntry`, `StackFrame` and `FPUContext` in the
>> user-defined functions handling code (`source/vm/fnpovfpu.h`) SHALL be
>> subject to change, now and forever more.
>> 
>> The commend currently preceding these data structures:
>> 
>> // WARNING: Do not change this structure without notice!!!
>> // Platform specific code may depend on the exact layout and size! [trf]
>> 
>> will be removed without replacement.
>> 
>> To the best of my knowledge there is not, and never has been, any
>> platform-specific code that does, or ever did, rely on these structures.
>> 
>> If I'm mistaken there, please let me know.
> 
> If I remember well, there was a JITC but only for the Macintosh version v3.6
> JITC for the PPC (G4, G5,â€¦)
> Maybe that was the reason for it?
> 
> Something someone should implement again for x86? ;-)
> 
> --
> Yvo

Look at perforce/povray/3.6-release/macintosh/backend/MacFastfunctions.cpp

-- 
Yvo

-- 
-------------------------------------------------------------------------------------------


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[Yvo Smellenbergh] Re: Official notice - user defined function VM d... [2878 days and 20 minutes ago]

Mon, 21 May 2018 16:37:54 GMT

On 2018-05-21 14:16:30 +0000, clipka said:

> Hear, hear, hear!
> 
> I hereby give the following notice:
> 
> The data types `FunctionEntry`, `StackFrame` and `FPUContext` in the
> user-defined functions handling code (`source/vm/fnpovfpu.h`) SHALL be
> subject to change, now and forever more.
> 
> The commend currently preceding these data structures:
> 
> // WARNING: Do not change this structure without notice!!!
> // Platform specific code may depend on the exact layout and size! [trf]
> 
> will be removed without replacement.
> 
> To the best of my knowledge there is not, and never has been, any
> platform-specific code that does, or ever did, rely on these structures.
> 
> If I'm mistaken there, please let me know.

If I remember well, there was a JITC but only for the Macintosh version v3.6
JITC for the PPC (G4, G5,â€¦)
Maybe that was the reason for it?

Something someone should implement again for x86? ;-)

--
Yvo

-- 
-------------------------------------------------------------------------------------------


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[clipka] Official notice - user defined function VM data ... [2878 days 2 hours and 41 minutes ago]

Mon, 21 May 2018 14:16:30 GMT

Hear, hear, hear!

I hereby give the following notice:

The data types `FunctionEntry`, `StackFrame` and `FPUContext` in the
user-defined functions handling code (`source/vm/fnpovfpu.h`) SHALL be
subject to change, now and forever more.

The commend currently preceding these data structures:

// WARNING: Do not change this structure without notice!!!
// Platform specific code may depend on the exact layout and size! [trf]

will be removed without replacement.

To the best of my knowledge there is not, and never has been, any
platform-specific code that does, or ever did, rely on these structures.

If I'm mistaken there, please let me know.

[clipka] Re: qtpovray [2878 days 8 hours and 48 minutes ago]

Mon, 21 May 2018 08:10:03 GMT

Am 21.05.2018 um 00:43 schrieb dick balaska:

> I have no idea no to get qmake to do super-optimization, i.e. use the
> libraries
> 
> .../platform/libx86avx.a ../platform/libx86avxfma4.a
> .../platform/libx86avx2fma3.a
> 
> There doesn't seem to be a "try/compile" thingy like in autoconf.

Here is how these things are supposed to work:

- The `platform/x86/FOO` directories contain source code hand-optimized
for particular instruction set extensions.

- It does not hurt to build and link _all_ of them: There is code in
place that will choose the best optimization _at run-time_ for whatever
x86 family CPU the binary actually happens to be running on. Most
importantly, that code will make sure that optimized code is _never_
invoked on a CPU that doesn't support the instruction set used therein.

- The reason we're compiling the instruction set specific code into
separate libraries is _not_ that we may want to exclude any of them, but
just that (1) g++ only accepts the hand-optimized code if we allow it to
use the same instruction set extensions in its own optimizations as
well, (2) we _must not_ allow instruction set extensions to be used
anywhere outside these particular files (because the functions therein
are the only ones guarded by run-time CPU detection), and (3) the
automake build process does not provide a mechanism to vary the compiler
settings on a per-file basis, so we need to place them in different
libraries.

In Visual Studio, this is different: There, instruction set switches
just govern compiler optimizations, while the instructions are always
available to hand-optimized code -- unless the compiler is too old to
support them at all, but that can easily be tested at compile time (and
the problematic code disabled accordingly) via preprocessor macros.

- The reason we have instruction set related tests in our autoconf build
process at all is _not_ to test whether the CPU supports them, but
merely whether the compiler does. A test for compiler brand and version
could conceivably do the same job, but in the autoconf framework a
direct test for compiler flags is the easier and more robust route.


So, to properly build the optimized code, there are two hurdles to overcome:

(1) Make sure the files in question are compiled with the corresponding
compiler flags, differing from the flags used for the other files. I'm
not sure how to do that with qmake, but from what I gather from the
internerds, `SUBDIRS` might be the keyword you want to search for.

The flags in question should be as follows:

/platform/x86/avx       -mavx
/platform/x86/avxfma4   -mavx -mfma4
/platform/x86/avx2fma3  -mavx2 -mfma  [sic!]

(2) Make sure the compiler in general supports the flags in question. My
guess would be that the easiest route with qmake is probably to detect
compiler brand and version, and from that decide which flags to use
(and, accordingly, which of the platform-specific source code files to
incldue in the build).

For GCC, the version numbers appear to be as follows:

-mfma4    since gcc 4.5
-mavx     since gcc 4.6
-mfma     since gcc 4.7
-mavx2    since gcc 4.7

For clang I have no corresponding information. From the perspective of
the source code, it mimicks the GCC signature and version numbers, so
there never was any need to research its own version history with
respect to the flags. (A potential problem with clang to watch out for
is that Apple's Xcode uses its own version of clang with a different
version numbering scheme.)

A very simple solution would be to require gcc 4.7 or later, or a
compatible clang version, as a prerequisite.

[dick balaska] qtpovray [2878 days 18 hours and 14 minutes ago]

Sun, 20 May 2018 22:43:30 GMT

I have an integrated Qt gui/povray that builds as a single executable.

git clone https://github.com/dickbalaska/povray.git
cd povray
git checkout qmake
qmake
make -j4
qt/gui/qtpovray		# run the executable

The gui behavior is exactly like, and has the same features as, 
http://www.buckosoft.com/qtpov/
(except you don't have to configure the povray executable, because it is 
built-in).

I have no idea no to get qmake to do super-optimization, i.e. use the 
libraries

../platform/libx86avx.a ../platform/libx86avxfma4.a 
../platform/libx86avx2fma3.a

There doesn't seem to be a "try/compile" thingy like in autoconf.

I still prefer the separate executables of the websockets edition.
1) Separation of gui from povray engine, i.e. "client/server"
2) automake for povray has more mature control of determining best 
compile conditions and processor features.

-- 
dik
Rendered 328976 of 330000 (99%)

[clipka] Re: Ray collision export, spectral rendering, an... [2924 days and 47 minutes ago]

Thu, 5 Apr 2018 16:10:48 GMT

Am 05.04.2018 um 15:22 schrieb Alexander jahn:

> a) is it possible to export text of the individual ray collision and
> diffraction?

Nope.

In POV-Ray, by design raytracing is only employed as a means to create
images, not as a goal in and of itself.

You /might/ be able to coax POV-Ray into writing /some/ rudimentary
ray-object collision "log" by using photons and writing the photon map
to a file, but that log would be far less detailed, IIRC have some
binary format, and would also require some tinkering with the scene to
set it up for this purpose.

Adding a dedicated "ray logging" mechanism to the code may be possible,
but probably non-trivial, especially since contemporary POV-Ray uses
symmetric multithreading so you can't just naively dump ray-object
intersection information to a file "on the fly".

> b) Is it possible to apply the attribute "wavelength" to an individual ray?
> In my setup, the wavelength of the light is very important, but most ray-tracers
> do not include that info afaik.
> The response to this question is important for question c)

For some mechanisms POV-Ray does indeed tag rays as monochromatic with
an associated wavelength, namely whenever dispersion comes into play.
(Note however that the tag and wavelength are only evaluated in
subsequent dispersive refraction events; colour computations are
/always/ done on an RGB basis.)

> c) Is it possible to simulate a reflective refraction grating?
> Example
> https://www.thorlabs.com/images/TabImages/Littrow_Configuration_D1-780.gif
> The main issue that I see is that it is not a particle effect, but rather an
> interference effect, using a ray-model of light is not the best way I guess.

At present, POV-Ray provides no way to model such a thing. I'm sure such
a feature could be added (given enough time and energy), but probably
only via a stochastic approach. (Someone would also have to come up with
a neat syntax for the feature, so that it fits nicely into POV-Ray's
current system of material properties.)

[Bald Eagle] Re: Ray collision export, spectral rendering, an... [2924 days 2 hours and 38 minutes ago]

Thu, 5 Apr 2018 14:20:00 GMT

With regard to the interference pattern, you might be able to define functions
to use as patterns in 3D space.

I'm thinking that if you define them with sinusoidal functions, the waves ought
to produce an interference pattern.

I did something like this in 2D.
http://news.povray.org/povray.binaries.animations/thread/%3C56dc130f%40news.povray.org%3E/
What you want to do is certainly more challenging.

Have a look at:


http://news.povray.org/povray.newusers/thread/%3CPkHU2EAlyv89Ewfz%40econym.demon.co.uk%3E/

http://news.povray.org/povray.general/thread/%3Cweb.4aadc07b57c09743f211c3700@news.povray.org%3E/?ttop=354036&toff=250

Also, Bill Pokorny plays around with some complicated projects - he might chime
in with something useful, and clipka might have some thoughts on addressing this
as well.

Just a few quick ideas.

[Bald Eagle] Re: Ray collision export, spectral rendering, an... [2924 days 2 hours and 48 minutes ago]

Thu, 5 Apr 2018 14:10:01 GMT

"Alexander jahn" <jah### [at] gmailcom> wrote:

> a) is it possible to export text of the individual ray collision and
> diffraction?
>
> For example
>
> output.txt:
> From To Source Destination DestinationType FromX FromY ToX ToY DeltaX DeltaY
> Magnitude BeamAngle SurfaceNormalAngle WavelengthNM
> Beam Origin Refraction Origin Ray 1 Dbeam 1 Crown lens Lens -5,0000 0,0000e+00
> -5,0000e-04 -0,2700 4,9995 -0,2700 5,0068 -3,0910 180,0000 650,0000
> Refraction Refraction Crown lens Crown lens Lens -5,0000e-04 -0,2700 0,7497
> -0,2966 0,7502 -0,0267 0,7507 -2,0357 174,3253 650,0000
> ....
> + another 500,000 lines like this
> (this output is 2D and is a normal export of
> https://arachnoid.com/OpticalRayTracer/ )
>
> I am interested in this text output as I will simulate my light-sensor as a
> sphere, the rays that collide with this sphere are "detected".

POV-Ray itself won't do that, but I suppose you might be able to do something
with the trace() function.  Might take a while.

> b) Is it possible to apply the attribute "wavelength" to an individual ray?
> In my setup, the wavelength of the light is very important, but most ray-tracers
> do not include that info afaik.
> The response to this question is important for question c)

If you somehow encode your "wavelength" as an rgb value, then I suppose it could
be possible.  For the moment, POV-Ray doesn't handle light in a realistic sense
like that.   But the following are the closest I can think of off the top of my
head:

http://www.ignorancia.org/en/index.php?page=Lightsys
http://www.lilysoft.org/CGI/SR/Spectral%20Render.htm

> c) Is it possible to simulate a reflective refraction grating?
> Example
> https://www.thorlabs.com/images/TabImages/Littrow_Configuration_D1-780.gif
> The main issue that I see is that it is not a particle effect, but rather an
> interference effect, using a ray-model of light is not the best way I guess.


Mmmmmm.   Dunno - but check out:
https://www.youtube.com/watch?v=xjMjWtntm9k

That might help you decide for yourself, or you could contact the author and see
how he went about it.

[Alexander jahn] Ray collision export, spectral rendering, and di... [2924 days 3 hours and 33 minutes ago]

Thu, 5 Apr 2018 13:25:01 GMT

Hello all,
for a simulation project of an optical system I would like to use POV-ray as a
standard in ray-tracing applications.
POV-ray already covers most of the necessary features but three things are
missing I think. I would like to ask here as extensive googling didn't lead to
any answer.

a) is it possible to export text of the individual ray collision and
diffraction?

For example

output.txt:
From To Source Destination DestinationType FromX FromY ToX ToY DeltaX DeltaY
Magnitude BeamAngle SurfaceNormalAngle WavelengthNM
Beam Origin Refraction Origin Ray 1 Dbeam 1 Crown lens Lens -5,0000 0,0000e+00
-5,0000e-04 -0,2700 4,9995 -0,2700 5,0068 -3,0910 180,0000 650,0000
Refraction Refraction Crown lens Crown lens Lens -5,0000e-04 -0,2700 0,7497
-0,2966 0,7502 -0,0267 0,7507 -2,0357 174,3253 650,0000
....
+ another 500,000 lines like this
(this output is 2D and is a normal export of
https://arachnoid.com/OpticalRayTracer/ )

I am interested in this text output as I will simulate my light-sensor as a
sphere, the rays that collide with this sphere are "detected".

b) Is it possible to apply the attribute "wavelength" to an individual ray?
In my setup, the wavelength of the light is very important, but most ray-tracers
do not include that info afaik.
The response to this question is important for question c)

c) Is it possible to simulate a reflective refraction grating?
Example
https://www.thorlabs.com/images/TabImages/Littrow_Configuration_D1-780.gif
The main issue that I see is that it is not a particle effect, but rather an
interference effect, using a ray-model of light is not the best way I guess.

But anyways, with a simplified model of a diffraction grating, it should be
possible to deliver reasonable results.

I imagine that the rays need to be refracted on a surface based on the angle
between ray and surface normal as well as wavelength-attribute of the ray (see
question b).


If some of this features already exist please point me into that direction. For
the missing feature, I'd like to include that feature myself in the code and
publish that on github, I'd like to request ideas how to implement that if
possible.

Thank you very much for your time and feedback

Alex

[William F Pokorny] Re: Re-Writing the BRICKS Pattern [2925 days 3 hours and 36 minutes ago]

Wed, 4 Apr 2018 13:21:20 GMT

On 04/04/2018 08:28 AM, Sven Littkowski wrote:
> texture
> {
>   brick // this pattern is just ideal for planks
>   MyWoodTexture
>   MyTarInbetweenTexture
>   brick_size < 5.00, 0.02, 0.40 > // that equals now to plank size
>   mortar 0.01 scale 3.0 // thickness of the material between planks
> 
> }

Pretty sure if you add texture block wrappers around your predefined 
textures what you wrote today will work. As in:

texture
{
   brick
   texture { MyWoodTexture }
   texture { MyTarInbetweenTexture }
   brick_size < 5.00, 0.02, 0.40 >
   mortar 0.01 scale 3.0
}

Block pattern texture lists need the texture block indicators. There are 
too pavement and tiling patterns. As for your second idea I believe 
macros is the only way today.

Bill P.

[Sven Littkowski] Re-Writing the BRICKS Pattern [2925 days 4 hours and 30 minutes ago]

Wed, 4 Apr 2018 12:28:09 GMT

My suggestion is, to make a small change on the BRICKS pattern to allow
- when stated inside a TEXTURE block - to accept textures and not only
pigments.

This would make it very easy to use the BRICKS pattern to generate
wooden planks for decks and floors. In fact, not only wooden planks are
then possible, but any texture, like stones, glasses, and so on.

It could be this way:

texture
{
 brick // this pattern is just ideal for planks
 MyWoodTexture
 MyTarInbetweenTexture
 brick_size < 5.00, 0.02, 0.40 > // that equals now to plank size
 mortar 0.01 scale 3.0 // thickness of the material between planks

}

------------------------------------

Also wondering if there is a way to "remote-control" textures from the
outside with parameters, similar to how MACRO allows to manipulate an
object from the outside with parameters. This could save us of having to
re-declare entire textures. With parameters, I could decide (for the
above example) which wood texture I want to use.

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[clipka] Re: What's in a name? [2998 days 6 hours and 34 minutes ago]

Sun, 21 Jan 2018 10:24:04 GMT

Am 21.01.2018 um 04:00 schrieb dick balaska:

>> - a build process shouldn't expect any of its build steps to core dump;
>> if a build tool is that unstable, it shouldn't be used at all.
> 
> It's not the build that cores, it's test/debug runs.Â  Clean also deletes
> *~ and *.bak and other hard coded detritus.

Apparently qmake tries to remove `./source/core`. For that to be a core
dump created during test/debug runs, it would need to run the binary
from `./source/`. That's one of the dumbest ideas I've heard in ages. If
that behaviour is hard-coded at any rate.

My personal guess is that the hard-coded removal of `core` was added
after /some/ user reported an issue where they were left with a core
dump as part of the build process, and instead of investigating the root
cause and solving it cleanly they just patched it up like that without
paying much thought.

Otherwise, if they had done some minimal research, they should at least
have included `core.*` in the list, as Linux systems may be configured
to generate core dumps as `core.PID` - or actually any file name the
administrator chooses. Not that this would solve the problem with the
`core` directory, but I think it is a good indicator of how little
thought went into that hard-coded makefile line.


> Ooh, ooh, I know.Â  Idiot. What I'll do is create
> ../qt/libpovray/libpovray.pro and build all of ./source from there. (I
> can access ../source).Â  That'll be messy too, I'll get ../../ blindness
> for sure. But it'll work, and it's better than renaming a primary
> directory.

That sounds neat.

In our Windows project files, we also have an army of `../../` to come
to our aid.

[dick balaska] Re: What's in a name? [2998 days 13 hours and 57 minutes ago]

Sun, 21 Jan 2018 03:00:22 GMT

On 01/20/2018 07:01 AM, clipka wrote:
> Am 20.01.2018 um 04:06 schrieb dick balaska:
>> I was always a little sad that povray uses *.ini and *.inc . Something
>> with a little more magic would have been nice instead of ubergenerics
>> that many compete for. ("Do you want to open MASM?", um no.)
> 
> Remember that back in the days when POV-Ray was originally created, you
> didn't open files from the operating system level; rather, you started
> the program that you knew would be able to open the file, and told that
> program to open the file.

Sure. And on my Amiga, .ini and .inc meant little.

> - a build process shouldn't expect any of its build steps to core dump;
> if a build tool is that unstable, it shouldn't be used at all.

It's not the build that cores, it's test/debug runs.  Clean also deletes 
*~ and *.bak and other hard coded detritus.

> - qmake should at least test whether `core` even is a regular file
> (which would be the case if it was a coredump) before attempting to
> delete it.

Agreed. "QMAKE_CLEAN -= core" at least should work.

> 
> Renaming the directory is a step I'd rather avoid; first, because I do
> think `core` is a fitting name, and second, because it would create a
> "fault line" in the source code version history.

Yeah, I didn't like it for historical reasons. And because I'm trying to 
be as unobtrusive as possible to the current source.

I renamed source/core to source/povcore just to move on. (Which meant 
editing every single source file that #include "core/blah.h")
I'm not married to the idea, in fact I hate it. But I do have 
libpovray.a and my qtpov built as one executable on Linux. (doesn't do 
shit yet, but it builds)

> 
> Can you avoid running qmake from the `./source/` directory? That would
> be the easiest way out. Remember that you may have two options there:

> 
> - Run qmake from the base directory (`./`).

I already do.  There are currently 4 .pro files.
./povray.pro - point to the other 3 .pro files and build them in this order:
./source/source.pro - build libpovray.a
./vfe/qt/qt.pro - build the vfe interface between libpovray.a and qt gui.
./qt/gui/gui.pro - build the qtpovray gui executable

I broke them up like that because they have different build needs.
Like libpovray is unaware of any Qt gui foo.

> - Run qmake for each sub-directory of `./source/` separately (i.e.
> `./source/backend/`, `./source/base/`, `./source/core/`, etc.

Ooh, ooh, I know.  Idiot. What I'll do is create 
./qt/libpovray/libpovray.pro and build all of ./source from there. (I 
can access ../source).  That'll be messy too, I'll get ../../ blindness 
for sure. But it'll work, and it's better than renaming a primary directory.

> 
> I concede that the latter isn't ideal in case more modules are added in
> the future, but maybe that's a bullet to bite. As for the only source
> file residing in `./source/` itself, `povmain.cpp`, the code in there is
> presumably irrelevant for your project.
> 

-- 
dik
Rendered 920576 of 921600 pixels (99%)

[clipka] Re: What's in a name? [2999 days 4 hours and 57 minutes ago]

Sat, 20 Jan 2018 12:01:03 GMT

Am 20.01.2018 um 04:06 schrieb dick balaska:
> I was always a little sad that povray uses *.ini and *.inc . Something
> with a little more magic would have been nice instead of ubergenerics
> that many compete for. ("Do you want to open MASM?", um no.)

Remember that back in the days when POV-Ray was originally created, you
didn't open files from the operating system level; rather, you started
the program that you knew would be able to open the file, and told that
program to open the file.


> Today I ran into ./source/core .
> As in:
> 
> rm -f libpovray.a
> rm -f *~ core *.core
> rm: cannot remove 'core': Is a directory
> Makefile:1034: recipe for target 'clean' failed
> 
> This is qmake foo.Â  core is hardcoded into the clean step. :(
> google says the only option is to rename this directory. :(
> (I fruitlessly tried "QMAKE_CLEAN -= core")

Hmm... the purpose seems to be to delete any coredump files created
during the build process, which would be named `core` - on /some/
systems at any rate.

I'm hesitant what to make of this. In my opinion, ...

- a build process shouldn't expect any of its build steps to core dump;
if a build tool is that unstable, it shouldn't be used at all.

- qmake should at least test whether `core` even is a regular file
(which would be the case if it was a coredump) before attempting to
delete it.

Renaming the directory is a step I'd rather avoid; first, because I do
think `core` is a fitting name, and second, because it would create a
"fault line" in the source code version history.

Can you avoid running qmake from the `./source/` directory? That would
be the easiest way out. Remember that you may have two options there:

- Run qmake from the base directory (`./`).
- Run qmake for each sub-directory of `./source/` separately (i.e.
`./source/backend/`, `./source/base/`, `./source/core/`, etc.

I concede that the latter isn't ideal in case more modules are added in
the future, but maybe that's a bullet to bite. As for the only source
file residing in `./source/` itself, `povmain.cpp`, the code in there is
presumably irrelevant for your project.

[dick balaska] What's in a name? [2999 days 13 hours and 51 minutes ago]

Sat, 20 Jan 2018 03:06:23 GMT

I was always a little sad that povray uses *.ini and *.inc . Something 
with a little more magic would have been nice instead of ubergenerics 
that many compete for. ("Do you want to open MASM?", um no.)

Today I ran into ./source/core .
As in:

rm -f libpovray.a
rm -f *~ core *.core
rm: cannot remove 'core': Is a directory
Makefile:1034: recipe for target 'clean' failed

This is qmake foo.  core is hardcoded into the clean step. :(
google says the only option is to rename this directory. :(
(I fruitlessly tried "QMAKE_CLEAN -= core")

-- 
dik
Rendered 344576 of 345600 pixels (99%)

[dick balaska] Re: qtpov [3018 days 18 hours ago]

Sun, 31 Dec 2017 22:57:40 GMT

I needed a color_map.  Rather than spend 2 minutes typing
	color_map{[0 color rgb<1.0000, 0.0000, 0.0000>]
	          [1 color rgb<0.0000, 1.0000, 0.0000>]

instead I spent several days writing a colormap editor. :)
http://www.buckosoft.com/qtpov/colormapEditor/


-- 
dik
Rendered 344576 of 345600 pixels (99%)

[dick balaska] qtpov 0.3 [3027 days 23 hours and 53 minutes ago]

Fri, 22 Dec 2017 17:04:25 GMT

qtpov 0.3 for Ubuntu 16 and Windows
http://www.buckosoft.com/qtpov/

Insert Menu - with token substitution
http://www.buckosoft.com/qtpov/insertText/

Advanced editing - indent/unindent blocks, toggle comments

Lots of menus (that do the same thing as the keys)

A stupid tutorial describing the minimum clicking and typing to get from 
download to a rendered file.
http://www.buckosoft.com/qtpov/tutorial/

--
dik

[clipka] Re: qtpov 0.2 [3036 days 5 hours and 50 minutes ago]

Thu, 14 Dec 2017 11:07:21 GMT

Am 14.12.2017 um 10:12 schrieb dick balaska:

> I was gonna say, "Well, my goal is to make it work first, and then
> polish it".Â  but instead I'll go with
> 
> Sir! How dare you?
> 
> Now I have to do this stupid thing that only half interests me, when I
> would much rather select a block of text and type Ctrl-/ to comment it
> out.Â  (Or select text and type Tab and have it indent instead of
> replacing the selection with a tab. That's irksome... Stupid program.)

So long as you have a UI for a more sophisticated mapping firmly on the
radar, and are just keeping things simple for the beginning, I'm happy.

[dick balaska] Re: qtpov 0.2 [3036 days 7 hours and 45 minutes ago]

Thu, 14 Dec 2017 09:12:24 GMT

On 12/14/2017 01:19 AM, clipka wrote:
> Am 14.12.2017 um 04:17 schrieb dick balaska:
> 
>> Adds a bookmark system.
>> http://www.buckosoft.com/qtpov/bookmarks/
> 
> Bookmarks are cool.
> Do they stick around when you close and re-open a file?

But of course! My goal is, exit and restart and you are exactly in the 
state you left it.
The part I think is cool is it remembers the docking state and size of 
all of the windows/widgets.

Eclipse's bookmarks can get confused about the line they live on. I 
always gave them a pass on that. But after writing it, it's like a 
single 4 variable formula!
     if (bmLine > cursorLine)
         bmLine += newLineCount-oldLineCount;

> 
> 
>> Configurable shortcuts/hotkeys.
>> http://www.buckosoft.com/qtpov/configure/keys.php
> 

> I'd love to see a genuine 1:N
> mapping, as supported e.g. by Microsoft Word.

I can create M shortcuts/keys and connect them to N functions.

At first I was thinking I need to see an example of a configuration UI. 
But I got something...

> Don't tell me Microsoft
> can create better UIs than you ;))

How dare you, sir!

I was gonna say, "Well, my goal is to make it work first, and then 
polish it".  but instead I'll go with

Sir! How dare you?

Now I have to do this stupid thing that only half interests me, when I 
would much rather select a block of text and type Ctrl-/ to comment it 
out.  (Or select text and type Tab and have it indent instead of 
replacing the selection with a tab. That's irksome... Stupid program.)

And for Ctrl-/ it made me realize; I never use the menus for 
Copy/Paste/Shift. But I do use the menus to see what features an editor 
supports and what hotkey it is. So I need to add a menu for 
Cut/Copy/Paste. Frowny face because I have to control it (Paste is 
dimmed if the buffer is empty.)

--
dik

[clipka] Re: qtpov 0.2 [3036 days 10 hours and 38 minutes ago]

Thu, 14 Dec 2017 06:19:38 GMT

Am 14.12.2017 um 04:17 schrieb dick balaska:

> Adds a bookmark system.
> http://www.buckosoft.com/qtpov/bookmarks/

Bookmarks are cool.
Do they stick around when you close and re-open a file?


> Configurable shortcuts/hotkeys.
> http://www.buckosoft.com/qtpov/configure/keys.php

While configurable keys are good, the example you're showing already
highlights the drawbacks of the approach you (and too many other pieces
of software) are using: Why force users to choose between F3 and Ctrl+K
for the "Move to next find" function, when you could assign the function
to /both/ keys?

(And no, computer games' half-assed approach of providing /two/ key
bindings per function doesn't nail it. I'd love to see a genuine 1:N
mapping, as supported e.g. by Microsoft Word. Don't tell me Microsoft
can create better UIs than you ;))

[dick balaska] Re: qtpov 0.2 [3036 days 13 hours and 37 minutes ago]

Thu, 14 Dec 2017 03:20:25 GMT

On 12/13/2017 10:17 PM, dick balaska wrote:
> qtpov-0.2

I like this picture
http://www.buckosoft.com/qtpov/g/qtpovRenderViewUndocked.png

-- 
dik

[dick balaska] Re: qtpov 0.2 [3036 days 13 hours and 41 minutes ago]

Thu, 14 Dec 2017 03:17:03 GMT

qtpov-0.2
http://www.buckosoft.com/qtpov/

Finish Find / Find in Files / Replace.
http://www.buckosoft.com/qtpov/find/

Adds a bookmark system.
http://www.buckosoft.com/qtpov/bookmarks/

Configurable shortcuts/hotkeys.
http://www.buckosoft.com/qtpov/configure/keys.php

--
dik

[dick balaska] qtpov 0.1 [3044 days 18 hours and 15 minutes ago]

Tue, 5 Dec 2017 22:42:30 GMT

To celebrate that I am working on my animation with qtpov, I have 
released version 0.1 on Windows and Linux (I am using the Linux edition).
http://www.buckosoft.com/qtpov/

Sure, there's still lots to do, but it works well.
I am to the point where I need to track my todo list; hi bugzilla.
http://www.buckosoft.com/qtpov/bugzilla

(clipka will be particularly interested in bug #2. ;)
http://www.buckosoft.com/qtpov/bugzilla/show_bug.cgi?id=2 )

The big feature in this release is navigable SDL errors.
http://www.buckosoft.com/qtpov/errors/

and you can set filters on the povray console and the resource/filelist 
tree.

There is most of a Find/Replace system in place. (Find-in-Files and 
replace aren't done).

--
dik

[dick balaska] Re: qtpov [3049 days 19 hours and 31 minutes ago]

Thu, 30 Nov 2017 21:26:23 GMT

Am 2017-11-30 16:08, also sprach clipka:
> Am 30.11.2017 um 21:29 schrieb dick balaska:
> 
>>> What tools are needed to build the Windows binaries?
>>>
>> vs2015 for povwebsockets.exe and Qt5 for qtpov.
> 
> What version of Qt is that exactly?
> 
I'm using 5.9.? on Linux (latest as of a month ago) and 5.8.0 on 
Windows, because I already had it installed.
The only non Qt-4.8 feature I'm aware that I used is the close boxes in 
the tabwidget, so I believe any 5.x version should work.

-- 
dik

[clipka] Re: qtpov [3049 days 19 hours and 49 minutes ago]

Thu, 30 Nov 2017 21:08:57 GMT

Am 30.11.2017 um 21:29 schrieb dick balaska:

>> What tools are needed to build the Windows binaries?
>>
> vs2015 for povwebsockets.exe and Qt5 for qtpov.

What version of Qt is that exactly?

The service we're using for automated build tests (and also automated
development builds) provides environments with VS2015 and various
versions of Qt5 starting from Qt 5.3 (currently 5.3, 5.4, 5.5, 5.6.2,
5.7.1, 5.8.0 and 5.9.2).

[dick balaska] Re: qtpov [3049 days 20 hours and 28 minutes ago]

Thu, 30 Nov 2017 20:29:22 GMT

Am 2017-11-30 07:09, also sprach clipka:
> Am 30.11.2017 um 10:53 schrieb dick balaska:
>> Am 2017-10-25 09:22, also sprach dick balaska:
>>> I started on qtpov.
>>
>> Runs on Windows 8.
>> http://www.buckosoft.com/qtpov/g/qtpovWindowsRendering.png
> 
> Love to hear that :)
> 
> I really need to have a closer look at what you're doing and how you're
> doing it... as soon as I find the time.
> 
> What tools are needed to build the Windows binaries?
> 
vs2015 for povwebsockets.exe and Qt5 for qtpov.
I'll write it up.
Weird, I put together a Windows Qt package for bsAniPic
( http://www.buckosoft.com/bsAniPic/ )
but I can't say the right magic words for qtpov. :) :(

As I've said, I am treating this as a learning exercise. I am getting 
into the whole vfe structure, so when it comes time to move to ./qt I'll 
already have experience and should make better choices, because it will 
be my second vfe.

qtpov works by launching and persisting a single instance of povray and 
then creating a new vfeSession for each render. This is the pvengine 
technique.  I noticed that Unix, I seem to leak about 70MB per render, 
and I bet myself that Windows would not leak, being that pvengine 
doesn't leak, and it doesn't.  So, that's a thing. (or, "top" lies. I 
haven't run valgrind or anything on it yet.)

-- 
dik

[clipka] Re: qtpov [3050 days 4 hours and 48 minutes ago]

Thu, 30 Nov 2017 12:09:42 GMT

Am 30.11.2017 um 10:53 schrieb dick balaska:
> Am 2017-10-25 09:22, also sprach dick balaska:
>> I started on qtpov.
> 
> Runs on Windows 8.
> http://www.buckosoft.com/qtpov/g/qtpovWindowsRendering.png

Love to hear that :)

I really need to have a closer look at what you're doing and how you're
doing it... as soon as I find the time.

What tools are needed to build the Windows binaries?

[dick balaska] Re: qtpov [3050 days 7 hours and 4 minutes ago]

Thu, 30 Nov 2017 09:53:31 GMT

Am 2017-10-25 09:22, also sprach dick balaska:
> I started on qtpov.

Runs on Windows 8.
http://www.buckosoft.com/qtpov/g/qtpovWindowsRendering.png


-- 
dik

[dick balaska] Re: qtpov [3053 days 12 hours and 51 minutes ago]

Mon, 27 Nov 2017 04:06:50 GMT

I have a qtpov-0.0.1 release (Linux only).
http://www.buckosoft.com/qtpov/

It's very primitive, but it has some bells and whistles.
http://www.buckosoft.com/qtpov/g/qtpovRenderInProgress.png

I have one bummer: When I throw a "render several frames at .5 seconds 
per frame" command at it, the bit that scales the in-progress image into 
the window is *slow*, and drags the event queue to a crawl. There's too 
many redraw events [1]. :(

There is a compiled binary package available. I have run it on 3 
different Ubuntu 16 boxes, but that's not much of a test, because they 
are all Ubuntu 16. The qtpov program runs on Ubuntu 14 (with the 
included .so files) but povrayws tips over on bad system libraries. It's 
best to build povrayws yourself.

--
dik

[1] So I start a render of 10 frames. The UI locks up as it furiously 
renders and displays the 10 frames. Around frame 5 I press "Cancel", 
which is the same button as "Render". It finishes the frames, sees the 
event on the button, which is now back to "Render" (because the job is 
done) and restarts the render job. argh.

[dick balaska] Re: qtpov [3059 days 6 hours and 39 minutes ago]

Tue, 21 Nov 2017 10:18:36 GMT

et voilÃ 

qtpov caught in mid-render.

http://www.buckosoft.com/qtpov/g/qtpovRenderInProgress.png

Two weird things, one in povray, one in qt.
1) povray frontend loses the vfeSession::MessageType info somewhere 
before it hits the vfe. I see mDivider, everything else (mDebug, mError) 
is mUnclassified. Line and Col are always 0, too.  I'll figure out what 
I'm doing wrong.
2) qt loses/ignores the last paint event when drawing a rendering image. 
If I wiggle with size bar, all of the data shows up. Um...

-- 
dik

[Mr] Re: qtpov [3060 days 1 hour and 43 minutes ago]

Mon, 20 Nov 2017 15:15:01 GMT

dick balaska <dic### [at] buckosoftcom> wrote:

> BTW, this is the colored editor:
> http://www.buckosoft.com/qtpov/
>
> --
> dik

The syntax being configurable is cool !
I don't know if you had a look, we kind of had lots of trial and errors to get
to a satisfying look for our Blender POV syntax highlight, so feel free to skim
throught the groups of words for ones you want or might have forgotten (of
course if you see some we missed I hope you'll tell us as well ;-))

https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/space_text/text_format_pov.c

Our INI support is slightly less fine grained:
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/space_text/text_format_pov_ini.c

[Thorsten Froehlich] Re: qtpov [3067 days 10 hours and 43 minutes ago]

Mon, 13 Nov 2017 06:15:01 GMT

dick balaska <dic### [at] buckosoftcom> wrote:
> One thing about vfe/POVMS, is that file I/O happens in both the frontend
> and backend. This currently limits the networking to localhost.

The code to handle this exchange file location information via POVMS is already
in 3.7. There just happens to be no code to actually transfer files over a
network.

Thorsten

[dick balaska] Re: qtpov [3067 days 12 hours and 49 minutes ago]

Mon, 13 Nov 2017 04:09:02 GMT

On 11/12/2017 01:00 AM, clipka wrote:
> Am 12.11.2017 um 00:56 schrieb dick balaska:
>> On 11/11/2017 03:53 PM, clipka wrote:
>>
>>> No, not a Qt based render engine -- just a Qt based program (which acts
>>> as a wrapper for the actual render engine) that you invoke from the GUI
>>> to render scenes.
>>
>> yes.
>>
>> Hmm, just to be sure we're on the same page,
> 
> I think we aren't yet. Somehow we're still talking different language here.

Ok.

>> there is no Qt in the povray source tree.
> 
> Of course not (yet). But if you write a Qt-based GUI, and we want to
> make it an official part of the POV-Ray package (to replace that
> outdated POV-Ray for Windows GUI, for instance), then obviously that
> means Qt-based code must get into the POV-Ray source tree.


> 
>> The "wrapper" is a separate program and
>> communicates via a socket.Â  My pollution to the source consists of
>> adding an std/boost based header only websocket library.
>> https://github.com/zaphoyd/websocketpp
>> (Although oddly, I had to add -lstd++ to the build for
>> std::basic_string, which I thought would have been there.)
> 
> I'm pretty sure that's not enough -- if the goal is for the Qt-based GUI
> to run on all Qt-supported platforms. And from my seat, that's exactly
> the goal.

Yes. I plan on demoing Linux and Windows, which is what I have available.

> 
> 
>> The --websockets option to ./prebuild.sh does a substitution of vfe/unix
>> with vfe/websockets.
> 
> We don't have `./prebuild.sh` on Windows. And just replacing the vfe
> package doesn't turn a Unix-specific application into a platform-neutral
> one.

No. I envision a third option in VS2015. Currently, there's "GUI" and 
"Console" iirc. I'd add a third option "Websockets".

> Besides, at this point I'm wondering whether you're doing the right
> thing with the websockets interface:

Ok.

> - The official interface between the UI and the actual parser/renderer
> system is the POVMS layer.
> 
> - The VFE layer was placed on top of that for easier use of the POVMS
> layer on the UI side.
> 
> - Now you're placing a third layer on top of that, to... well, why
> exactly? Separate the GUI from the actual parser/renderer system?

Yes, separate the GUI from the render system. I'm trying to be as 
unobtrusive as possible to the current povray source tree.

> 
> I'd like to point out here that although the POVMS layer is currently
> only used to communicate between different threads of the same process,
> it was originally designed specifically as an interface to be used
> between separate processes or even over a network connection. So rather
> than bolt websockets on top of the VFE layer, it seems to me the right
> thing to do would be to integrate it /into/ POVMS as a channel to
> transport POVMS messages. Think POVMS-over-websockets.

Hmm, interesting. I didn't notice the network aspects of POVMS, but I 
wasn't looking. That would be a lot tighter binding than I was 
contemplating.

One thing about vfe/POVMS, is that file I/O happens in both the frontend 
and backend. This currently limits the networking to localhost.

> I don't claim that to be an easy task, as I do expect some weed still in
> there that needs removing. (Somewhen during the development of v3.7.0,
> the strict use of the POVMS layer had been eroded quite significantly,
> with the VFE communicating directly with the parser/renderer subsystem
> at various points. I've been trimming down that wild growth since, but
> there may still be remnants of that eposide lurking in there.)
> 
> So your Qt-based GUI should really access either VFE or POVMS directly
> (or via a layer running in the same process), with the actual
> inter-process communication happening within the POVMS layer.

Yes. What I have done is subclass vfeSession. Instead of vfeUnixSession 
there is now vfeWebsocketSession.  I think it will be easy to flesh out 
vfeWebsocketSession because I have a working model of what I need to 
feed vfeSession with the existing vfeUnixSession.


> 
>> The source files in $(povray)/unix are now unused (display a picture),
>> but I need the control foo in there. I think the same thing happens to
>> $(povray)/windows, too. The *.cpp go away but the vs2015 directory, at
>> least, will remain.
> 
> That is something that I think we should avoid. (And physically removing
> files from the tree is a no-go, obviously.)

s/go away/will be unused in the websockets incarnation/

> 
> Qt is a platform-independent framework, so I'd presume it provides
> /some/ mechanism to manage the build process in a platform-independent
> manner (possibly by maintaining build information in a platform-neutral
> form, and auto-generating platform-specific build information from that,
> just like we currently do with our Unix `prebuild.sh` script).

Yes, ain't nothing to a Qt makefile.
http://git.buckosoft.com/gitweb/pov.cgi?p=qtpov.git;a=blob_plain;f=qtpov.pro;hb=HEAD

There is obviously a lot of magic happening behind the scenes to turn 
that into:
g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC 
-DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB 
-DQT_CORE_LIB -I../qtpov -I. -I/opt/Qt/5.9.1/gcc_64/include 
-I/opt/Qt/5.9.1/gcc_64/include/QtWidgets 
-I/opt/Qt/5.9.1/gcc_64/include/QtGui 
-I/opt/Qt/5.9.1/gcc_64/include/QtCore -I. -isystem /usr/include/libdrm 
-I. -I/opt/Qt/5.9.1/gcc_64/mkspecs/linux-g++ -o mainwindow.o 
../qtpov/mainwindow.cpp

One nice thing about Qt, is the Windows version supports gcc/MinGW and 
VS2015 compilers. I use the VS2015 because it seems to have more robust 
debugging and seems to generate faster code, at least for bsAniPic.

> 
> So anything specific to the Qt-based incarnation of POV-Ray should
> reside in its own dedicated directory (say, `./qt`, instead of `./unix`
> or `./windows`, respectively).

> - A Qt-based GUI for POV-Ray has to /either/ constitute an "incarnation"
> of POV-Ray in its own right, /or/ invoke some "incarnation" to do the
> actual work. In the latter case (which I understand is your approach),
> this should ideally be a portable "incarnation" (and thus necessarily a
> new one, ideally based on Qt as well), again lest the biggest benefit of
> Qt be wasted.
> 

All right, I think I see.  You envision a single unified build based on 
Qt.  The GUI and the engine build to make one big happy program.

I could spend months learning and tweaking the Qt build system and CPU 
optimizations to build a well optimized backend. If rendering is 5% 
slower, the users won't adopt it.  This is not my strength, and I'm not 
interested in it at this time. I just want to make it work so I can get 
back to my animation. :)

So Phase 1, I'm going to continue on my websockets, separate source, 
separate build, plan. If it dies, it dies. If it turns out good, then
Phase 2 will be move the GUI tree to ./qt and get the whole thing to 
build with Qt.
Phase 3 will be remove the websockets and give the GUI either a direct 
vfe interface or maybe POVMS.

Sound ok to you?

-- 
dik

[clipka] Re: qtpov [3068 days 10 hours and 57 minutes ago]

Sun, 12 Nov 2017 06:00:48 GMT

Am 12.11.2017 um 00:56 schrieb dick balaska:
> On 11/11/2017 03:53 PM, clipka wrote:
> 
>> No, not a Qt based render engine -- just a Qt based program (which acts
>> as a wrapper for the actual render engine) that you invoke from the GUI
>> to render scenes.
> 
> yes.
> 
> Hmm, just to be sure we're on the same page,

I think we aren't yet. Somehow we're still talking different language here.

> there is no Qt in the povray source tree.

Of course not (yet). But if you write a Qt-based GUI, and we want to
make it an official part of the POV-Ray package (to replace that
outdated POV-Ray for Windows GUI, for instance), then obviously that
means Qt-based code must get into the POV-Ray source tree.

> The "wrapper" is a separate program and
> communicates via a socket.Â  My pollution to the source consists of
> adding an std/boost based header only websocket library.
> https://github.com/zaphoyd/websocketpp
> (Although oddly, I had to add -lstd++ to the build for
> std::basic_string, which I thought would have been there.)

I'm pretty sure that's not enough -- if the goal is for the Qt-based GUI
to run on all Qt-supported platforms. And from my seat, that's exactly
the goal.

>> It appears to me that the way you're approaching it, that would be a
>> replacement for both the Unix command-line version as well as
>> povconsole.exe.
> 
> Yes. And it's the "replacement" part that I internally debate.Â  I have
> chosen to generate povrayws as a separate unix binary to povray, because
> the unix frontend (command line parser) is ripped out and replaced.
> 
> But I wonder if instead I should have kept a single binary with a new
> povray option -N4401 to switch to the websockets version at runtime.
> The vfe(s) are nicely thin, and I don't see a problem switching to that
> technique if later it is preferred.

It doesn't matter whether you add a websockets interface to the existing
Unix binary, or create a new Unix binary with the command-line parser
replaced by a websockets interface: Neither binary will run on Windows,
and thus your Qt-based GUI will be mostly useless on Windows.

> The --websockets option to ./prebuild.sh does a substitution of vfe/unix
> with vfe/websockets.

We don't have `./prebuild.sh` on Windows. And just replacing the vfe
package doesn't turn a Unix-specific application into a platform-neutral
one.

Besides, at this point I'm wondering whether you're doing the right
thing with the websockets interface:

- The official interface between the UI and the actual parser/renderer
system is the POVMS layer.

- The VFE layer was placed on top of that for easier use of the POVMS
layer on the UI side.

- Now you're placing a third layer on top of that, to... well, why
exactly? Separate the GUI from the actual parser/renderer system?

I'd like to point out here that although the POVMS layer is currently
only used to communicate between different threads of the same process,
it was originally designed specifically as an interface to be used
between separate processes or even over a network connection. So rather
than bolt websockets on top of the VFE layer, it seems to me the right
thing to do would be to integrate it /into/ POVMS as a channel to
transport POVMS messages. Think POVMS-over-websockets.

I don't claim that to be an easy task, as I do expect some weed still in
there that needs removing. (Somewhen during the development of v3.7.0,
the strict use of the POVMS layer had been eroded quite significantly,
with the VFE communicating directly with the parser/renderer subsystem
at various points. I've been trimming down that wild growth since, but
there may still be remnants of that eposide lurking in there.)

So your Qt-based GUI should really access either VFE or POVMS directly
(or via a layer running in the same process), with the actual
inter-process communication happening within the POVMS layer.

> At first, I thought ./prebuild.sh was really overengineered. It is the
> most complicated automake system I've ever seen. (A script to create
> ../configure.in and massive Makefile.in(s) ? Why not just have those
> files?) But it works for me because now I do the directory
> substitutions. :)

The `prebuild.sh` script is not an automake system -- rather, it is a
pre-processing script designed to keep our repository as free from
build-process-specific stuff as possible. Most notably, the script:

- /Creates/ certain autotools-specific files from platform-neutral
sources, in order to avoid having to maintain the redundant information
in those autotools-specific files manually.

- /Copies/ other autotools-specific files from other locations to the
root directory of the package, in order to avoid cluttering the root
directory with stuff only required by one particular build process.

> platform/[unix|windows] has to stay because that is backend system grunt
> work (timers).Â  I don't know if I see value in platform/qt. Do you
> really want to drag in all of the Qt baggage (custom build system,
> custom packaging) just to provide a backend timer. -- If it ain't
> broken, don't fix it.

Ultimately? Yes, I'd like to see a `platform/qt` (in /addition/ to the
existing `platform/*`, mind you), if only because it would instantly
allow us to support a number of additional platforms -- anything
supported by Qt.

In the short run? No. As I said, I expect it easy to replace further
down the road, so why bother when there's still more important stuff in
the way.

> The source files in $(povray)/unix are now unused (display a picture),
> but I need the control foo in there. I think the same thing happens to
> $(povray)/windows, too. The *.cpp go away but the vs2015 directory, at
> least, will remain.

That is something that I think we should avoid. (And physically removing
files from the tree is a no-go, obviously.)

Qt is a platform-independent framework, so I'd presume it provides
/some/ mechanism to manage the build process in a platform-independent
manner (possibly by maintaining build information in a platform-neutral
form, and auto-generating platform-specific build information from that,
just like we currently do with our Unix `prebuild.sh` script).

So anything specific to the Qt-based incarnation of POV-Ray should
reside in its own dedicated directory (say, `./qt`, instead of `./unix`
or `./windows`, respectively).

I think it is important that we distinguish between what I like to refer
as "platforms" and "incarnations":

- When I talk about "platforms", I think of certain low-level
functionality that is essential for POV-Ray on each and every operating
system, but which can't be implemented in a portable fashion. For
instance the `file_exists()` scene language function requires that we
can determine whether a file exists or not, but on Windows this needs a
different function call than on Unix. In order to solve this, we have
"platform-specific" code tucked away in `./platform` (and probably other
places as well, but those will be weeded out in the long run).

- On the other hand we have "POV-Ray for Windows" and "POV-Ray for
Unix", which I'd like to refer to as "incarnations" of POV-Ray. And
while they happen to run on different platforms, and need different code
to e.g. test whether a directory exists, it's not their main difference.
Instead, they're really different pieces of software, which just happen
to share certain pieces of code (namely the stuff residing in
`./source`, plus a few odds & ends like platform-neutral portions of the
VFE). These should be tucked away in `./windows` and `./unix`,
respectively. Other "incarnations" also exist, such as Yvo's version for
Mac OS, which comes with its own GUI (and presumably uses
platform-specific code for Unix), and I'd also consider the
command-line-only version for Windows a separate "incarnation".

When talking about Qt, we have the same duality:

- As a framework for creating platform-independent software, Qt surely
must provide its own interface to do stuff such as determining whether a
particular file exists or not. While this will actually be a wrapper, it
makes sense of thinking of it as yet another "platform". And any
"incarnation" designed to make use of Qt should better also make use of
this "platform", lest the biggest benefit of Qt -- portability -- be wasted.

- A Qt-based GUI for POV-Ray has to /either/ constitute an "incarnation"
of POV-Ray in its own right, /or/ invoke some "incarnation" to do the
actual work. In the latter case (which I understand is your approach),
this should ideally be a portable "incarnation" (and thus necessarily a
new one, ideally based on Qt as well), again lest the biggest benefit of
Qt be wasted.

[dick balaska] Re: qtpov [3068 days 17 hours and 1 minute ago]

Sat, 11 Nov 2017 23:56:34 GMT

On 11/11/2017 03:53 PM, clipka wrote:

> No, not a Qt based render engine -- just a Qt based program (which acts
> as a wrapper for the actual render engine) that you invoke from the GUI
> to render scenes.

yes.

Hmm, just to be sure we're on the same page, there is no Qt in the 
povray source tree.  The "wrapper" is a separate program and 
communicates via a socket.  My pollution to the source consists of 
adding an std/boost based header only websocket library.
https://github.com/zaphoyd/websocketpp
(Although oddly, I had to add -lstd++ to the build for 
std::basic_string, which I thought would have been there.)

> It appears to me that the way you're approaching it, that would be a
> replacement for both the Unix command-line version as well as
> povconsole.exe.

Yes. And it's the "replacement" part that I internally debate.  I have 
chosen to generate povrayws as a separate unix binary to povray, because 
the unix frontend (command line parser) is ripped out and replaced.

But I wonder if instead I should have kept a single binary with a new 
povray option -N4401 to switch to the websockets version at runtime.
The vfe(s) are nicely thin, and I don't see a problem switching to that 
technique if later it is preferred.

> 
> The reason being that ideally the system as a whole should run on /any/
> platform supported by Qt, not just those for which we /happen/ to
> already have a command-line version of POV-Ray.
> 
> In terms of source files, this means that your system should compile and
> run fine without any of the files residing in `unix`, `windows`,
> `vfe/unix` or `vfe/win`, and ultimately even without any of the files in
> `platform/unix` or `platform/windows` (though these last two are
> probably comparatively easy to fix further down the road, by
> establishing some `platform/qt` instead).
> 

The --websockets option to ./prebuild.sh does a substitution of vfe/unix 
with vfe/websockets.
At first, I thought ./prebuild.sh was really overengineered. It is the 
most complicated automake system I've ever seen. (A script to create 
./configure.in and massive Makefile.in(s) ? Why not just have those 
files?) But it works for me because now I do the directory substitutions. :)

platform/[unix|windows] has to stay because that is backend system grunt 
work (timers).  I don't know if I see value in platform/qt. Do you 
really want to drag in all of the Qt baggage (custom build system, 
custom packaging) just to provide a backend timer. -- If it ain't 
broken, don't fix it.

The source files in $(povray)/unix are now unused (display a picture), 
but I need the control foo in there. I think the same thing happens to 
$(povray)/windows, too. The *.cpp go away but the vs2015 directory, at 
least, will remain.

-- 
dik

[clipka] Re: qtpov [3068 days 20 hours and 4 minutes ago]

Sat, 11 Nov 2017 20:53:25 GMT

Am 11.11.2017 um 21:15 schrieb dick balaska:
> On 11/11/2017 08:04 AM, clipka wrote:
> 
>> Uh... wait!
>> Unix binary?
>> If you go for Qt, then by all means please make sure the system in its
>> entirety is portable.
>> I'd presume that if you really go for separating the GUI from the
>> program that renders scenes, this means writing a new Qt-based instance
>> of the latter.
>>
> 
> A Qt based render engine? Why?Â  There is already a cross platform render
> engine. I want to leverage that as much as possible.
> What I'm doing is a separate source tree for qtpov. This is the gui.
> The gui launches povray (or povconsole.exe) and connects to it via a
> websocket. Then the gui can instruct povray to start a render and
> receive the 5 streams and in-progress graphics info.

No, not a Qt based render engine -- just a Qt based program (which acts
as a wrapper for the actual render engine) that you invoke from the GUI
to render scenes.

It appears to me that the way you're approaching it, that would be a
replacement for both the Unix command-line version as well as
povconsole.exe.

The reason being that ideally the system as a whole should run on /any/
platform supported by Qt, not just those for which we /happen/ to
already have a command-line version of POV-Ray.

In terms of source files, this means that your system should compile and
run fine without any of the files residing in `unix`, `windows`,
`vfe/unix` or `vfe/win`, and ultimately even without any of the files in
`platform/unix` or `platform/windows` (though these last two are
probably comparatively easy to fix further down the road, by
establishing some `platform/qt` instead).

[dick balaska] Re: qtpov [3068 days 20 hours and 42 minutes ago]

Sat, 11 Nov 2017 20:15:53 GMT

On 11/11/2017 08:04 AM, clipka wrote:

> Uh... wait!
> Unix binary?
> If you go for Qt, then by all means please make sure the system in its
> entirety is portable.
> I'd presume that if you really go for separating the GUI from the
> program that renders scenes, this means writing a new Qt-based instance
> of the latter.
> 

A Qt based render engine? Why?  There is already a cross platform render 
engine. I want to leverage that as much as possible.
What I'm doing is a separate source tree for qtpov. This is the gui.
The gui launches povray (or povconsole.exe) and connects to it via a 
websocket. Then the gui can instruct povray to start a render and 
receive the 5 streams and in-progress graphics info.

I assume portability. I'm just doing the work on Ubuntu 16. I'm not 
looking forward to doing the Windows version since my Windows 8 now is 
limited to a 1024x768 window inside VirtualBox. Visual Studio will be 
fun in that.

I have bsAniPic, a Qt picture viewer using the same API as qtpov. I 
wrote and packaged that on Windows.  I built it on Linux, but I failed 
in packaging it. I have built other c++ based .deb packages, but Qt is a 
bit of a beast.   I figure I'll really work that bit out once I have 
something worth showing in qtpov.

BTW, this is the colored editor:
http://www.buckosoft.com/qtpov/

-- 
dik

[clipka] Re: qtpov [3069 days 3 hours and 53 minutes ago]

Sat, 11 Nov 2017 13:04:16 GMT

Am 11.11.2017 um 09:41 schrieb dick balaska:
> On 10/25/2017 09:22 AM, dick balaska wrote:
>> I started on qtpov.
> 
> I got a bit sidetracked with making a configurable colored editor,
> because *that's* important. (It's better to look good than to feel good,
> and darling, you look mahvelous).

I hear you. With all the computer games I intended to write as a kid, I
/did/ always complete the title screen ;)


> Also, that gave me time to contemplate how best to attack websockets[1].
> 
> I was going to piggyback on the unix build and add a -N4041 option to
> open a listen port on 4041. Without the option, it'd be a regular unix
> build.
> 
> Perhaps a better approach, certainly easier, is to replace the unix
> frontend with a websocket frontend. This is due to the message system
> being point-to-point, instead of a buss.
> 
> I have the basic program built. It is DDS[2] but it builds.
> I changed ./prebuild.sh to take a --websockets option to cause it to
> generate the correct Makefiles. I'm not sure I like that from a user's pov.
> 
> I keep going back and forth as to whether the separate websockets binary
> is better than a single unix binary that does traditional and websockets.

Uh... wait!
Unix binary?
If you go for Qt, then by all means please make sure the system in its
entirety is portable.
I'd presume that if you really go for separating the GUI from the
program that renders scenes, this means writing a new Qt-based instance
of the latter.

[dick balaska] Re: qtpov [3069 days 8 hours and 16 minutes ago]

Sat, 11 Nov 2017 08:41:53 GMT

On 10/25/2017 09:22 AM, dick balaska wrote:
> I started on qtpov.

I got a bit sidetracked with making a configurable colored editor, 
because *that's* important. (It's better to look good than to feel good, 
and darling, you look mahvelous).

Also, that gave me time to contemplate how best to attack websockets[1].

I was going to piggyback on the unix build and add a -N4041 option to 
open a listen port on 4041. Without the option, it'd be a regular unix 
build.

Perhaps a better approach, certainly easier, is to replace the unix 
frontend with a websocket frontend. This is due to the message system 
being point-to-point, instead of a buss.

I have the basic program built. It is DDS[2] but it builds.
I changed ./prebuild.sh to take a --websockets option to cause it to 
generate the correct Makefiles. I'm not sure I like that from a user's pov.

I keep going back and forth as to whether the separate websockets binary 
is better than a single unix binary that does traditional and websockets.

-- 
dik

[1] It's a stupid name.  Akin to javascript being a stupid name.
[2] DDS - Doesn't Do Shit.

[Thorsten Froehlich] Re: qtpov [3086 days 1 hour and 8 minutes ago]

Wed, 25 Oct 2017 15:50:01 GMT

dick balaska <dic### [at] buckosoftcom> wrote:
> I started on qtpov.
> http://www.buckosoft.com/qtpov/g/qtpov.png
> I wanted to be further along before saying anything, but...
>
> I thought I remembered that povray used a message bus system, and I was
> going to hook up a websocket server to that.
> http://www.buckosoft.com/qtpov/g/qtpovPrefs.png
> :)
> Then, I can emit websocket messages for parse errors, % completion, and
> graphics data, etc.  I'm still trying to grok the povray message system,
> but it looks to be more point-to-point.
>
> qtpov (the editor) will launch povray and connect to it.  This is
> reversed from the Windows paradigm of pvengine calling the editor in a DLL.

I just sent you an email with a link to a full repository with a QT frontend
that I just never finished. It shows you how to do all the stuff needed with
regard to networking and does work.

The main catch is that it is based on a way different source tree than the (now)
mainline 3.7, hence some backporting will be required. But given I designed and
wrote POVMS, a diff with the approprite source tree version (a late 3.7 beta)
will give you all the clues you need, I suppose. And you can just email me if
you have questions about the source, too.

The code is all AGPL of course, I just don't want to support it officially, and
I really don't want to put a 133 MB source archive link here either.

Thorsten

[clipka] Re: qtpov [3086 days 1 hour and 55 minutes ago]

Wed, 25 Oct 2017 15:02:47 GMT

Am 25.10.2017 um 15:22 schrieb dick balaska:
> I started on qtpov.
> http://www.buckosoft.com/qtpov/g/qtpov.png

Go for it!

If you need /any/ assistance whatsoever, let us know.

Developing some brand-spanking-new frontend based on a
platform-independent framework has been on our agenda for quite a while
now (and as it happens Qt was our first choice for that purpose as
well), but none of the dev team has managed to collect enough Round
Tuits(tm) so far to actually make it happen.

> I wanted to be further along before saying anything, but...

It's further than I had come ;)


> qtpov (the editor) will launch povray and connect to it.Â  This is
> reversed from the Windows paradigm of pvengine calling the editor in a DLL.

In the terminology we usually apply to POV-Ray for Windows, qtpov
wouldn't be a called an editor, but a GUI. The "editor" in POV-Ray for
Windows is really just the 3rd-party syntax-highlighted multi-line text
input component.

[dick balaska] qtpov [3086 days 3 hours and 36 minutes ago]

Wed, 25 Oct 2017 13:22:11 GMT

I started on qtpov.
http://www.buckosoft.com/qtpov/g/qtpov.png
I wanted to be further along before saying anything, but...

I thought I remembered that povray used a message bus system, and I was 
going to hook up a websocket server to that.
http://www.buckosoft.com/qtpov/g/qtpovPrefs.png
:)
Then, I can emit websocket messages for parse errors, % completion, and 
graphics data, etc.  I'm still trying to grok the povray message system, 
but it looks to be more point-to-point.

qtpov (the editor) will launch povray and connect to it.  This is 
reversed from the Windows paradigm of pvengine calling the editor in a DLL.



-- 
dik

[omniverse] Re: CSG Bounding box algorithm [3147 days 4 hours and 53 minutes ago]

Fri, 25 Aug 2017 12:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Looks like the b'box computation for quadrics (sorry, not quartics; got
> that wrong in the previous post) fails to respect the `inverse` keyword
> for /some/ reason.

Curiouser and curiouser, I was able to get the correct CSG shape (almost) by
changing the Cylinder_Y to:

 quadric
  {<1, 0, 1>,
   <0, 0.000000001, 0>, // one billionth
   <0, 0, 0>, -1
  }

Not perfect because of a slight xz offset, which can be seen when enclosing it
with semi-transparent cylinders with the same size.

Not only that, this causes Bald Eagle's bounding macro to go wild, reporting the
dimensions to be 10 billion in every direction from <0,0,0>.

Seems like a precision problem, but I wouldn't know so thought I would mention
this here in case it means something.

[Bald Eagle] Re: CSG Bounding box algorithm [3147 days 22 hours and 23 minutes ago]

Thu, 24 Aug 2017 18:35:00 GMT

"omniverse" <omn### [at] charternet> wrote:

> Well that's something I've needed time and again!
> Imagine how a render display would look if it could show arrows and labels for
> everything outside of view (ignoring the potential complexity!), or a way to
> make the camera find things with a simple look_at ObjectName (by extracting its
> defined location vector).

Yes, that's why I wrote it - I may have posted it here, if not, I'll do so soon
(remind me if I have a memory lapse)

There may be some include file / usage flag coding errors, but I hope to get
those fixed soon.

[incidentally, there are some issues with things like shapes2.inc that require
shapes.inc to work without error ...]

I'm also working on some experimental code to make "parameterized shapes" -
where you can have easy access to pre-calculated things like corners or edges or
faces of cubes, etc., as well as assign an object number to each new thing you
add to a scene.

I think that with a raytracer where mostly everything is defined with code, then
there needs to be a lot more helpful tools and examples, and algorithms, and
newbie-friendly, or advanced-accelerating snippets so that there aren't so many
instances where a seemingly small task turns into a computer-science-coding
_project_ to get past that single hurdle.

[omniverse] Re: CSG Bounding box algorithm [3147 days 23 hours and 23 minutes ago]

Thu, 24 Aug 2017 17:35:03 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "omniverse" <omn### [at] charternet> wrote:
>
> > Oops, yep, quadric is what I meant too. Checked with versions 3.6.2, 3.7.0 and
> > that same Rook example I posted here is okay. It's 3.7.1-rc1 causing the missing
> > parts. Likewise same for beta 9.
>
> Looks like I have a real knack for finding these little bugs - even when I don't
> know they're there, and I'm doing something completely wrong and pointless  :D
>
> > And I forget about the ability to show those bounding boxes too. Or so I
> > thought... hmmmm... doesn't Vista_Buffer=on or +UV do that?
> > Tried just now in v3.6.2, v3.7.0, v3.7.1-beta9 and v3.7.1-rc1, nothing seen of
> > bounding boxes in render window.
>
> That would be a neat feature!
> I checked the docs and didn't see anything like that.

Found what it was, Draw_Vistas=on or +UD on command line, goes back to v3.1g.
Although I'm not seeing it in v3.6.2 and above there's actually a message stream
acknowledgement of it being "on".

See v3.1g doc: http://www.cacr.caltech.edu/~slombey/asci/povray/pov134.htm

> I've written my own bounding-box visualization macro to do that, as well as show
> the min/max extent in the debug window ("WHERE'D my object{} go????")
> I think I threw in my camera-object-distance based auto-cylinder radius thing to
> give a nice consistent look to it as well whether it's 5 units or 50,000 units
> from the camera.
> Still needs a slight bit of fine-tuning.

Well that's something I've needed time and again!
Imagine how a render display would look if it could show arrows and labels for
everything outside of view (ignoring the potential complexity!), or a way to
make the camera find things with a simple look_at ObjectName (by extracting its
defined location vector).

[Bald Eagle] Re: CSG Bounding box algorithm [3148 days 4 hours and 53 minutes ago]

Thu, 24 Aug 2017 12:05:01 GMT

"omniverse" <omn### [at] charternet> wrote:

> Oops, yep, quadric is what I meant too. Checked with versions 3.6.2, 3.7.0 and
> that same Rook example I posted here is okay. It's 3.7.1-rc1 causing the missing
> parts. Likewise same for beta 9.

Looks like I have a real knack for finding these little bugs - even when I don't
know they're there, and I'm doing something completely wrong and pointless  :D

> And I forget about the ability to show those bounding boxes too. Or so I
> thought... hmmmm... doesn't Vista_Buffer=on or +UV do that?
> Tried just now in v3.6.2, v3.7.0, v3.7.1-beta9 and v3.7.1-rc1, nothing seen of
> bounding boxes in render window.

That would be a neat feature!
I checked the docs and didn't see anything like that.
I've written my own bounding-box visualization macro to do that, as well as show
the min/max extent in the debug window ("WHERE'D my object{} go????")
I think I threw in my camera-object-distance based auto-cylinder radius thing to
give a nice consistent look to it as well whether it's 5 units or 50,000 units
from the camera.
Still needs a slight bit of fine-tuning.

[Bald Eagle] Re: CSG Bounding box algorithm [3148 days 5 hours and 3 minutes ago]

Thu, 24 Aug 2017 11:55:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> There is no generic algorithm to compute the exact b'box of an
> intersection. Each specific combination of primitives would need its own
> algorithm.

Sorry - I was having a hard time understanding exactly what the situation was,
and not having access to that page and the SDL for those specific instances left
me to my own devices.   And by that time, I was pretty damned tired, so ....

> ??? Why would you need special handling for the quadrants?

Because I was just adapting some internet question-answerer's ridiculous code,
and they had a zero in their min/max formulae - presumably because they were
concerned with the _volume_ of the intersection .... and I was just too frazzled
to work it out from scratch like I should have.

> To compute the intersection of multiple axis-aligned b'boxes, all you
> need to do is get the highest low bounds for all axes and the lowest
> high bound for all axes.

Yes, I suspected that, but the Little Voice was too tiny, and my fatigued brain
inertia was too strong.

> Yes: All cases and none at all. Almost /any/ combination of primitives
> can be used to come up with pathological cases.

I see that a lot better now, and understand what those docs were getting at -
and why those cases present such difficulty.  Sometimes, for whatever reason,
the wording of some sections makes it a little hard to follow.

[omniverse] Re: CSG Bounding box algorithm [3148 days 7 hours and 8 minutes ago]

Thu, 24 Aug 2017 09:50:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 24.08.2017 um 03:04 schrieb omniverse:
>
> > I was wondering about this after coming across something about the automatic
> > bounding from the version 3.5 sample scene chess2.pov while rendering some of
> > those old files.
> ...
> > According to what is said here, I suppose that particular CSG object must be a
> > problem due to the intersecting planes and quartics (infinite shapes).
>
> Looks like the b'box computation for quadrics (sorry, not quartics; got
> that wrong in the previous post) fails to respect the `inverse` keyword
> for /some/ reason.

Oops, yep, quadric is what I meant too. Checked with versions 3.6.2, 3.7.0 and
that same Rook example I posted here is okay. It's 3.7.1-rc1 causing the missing
parts. Likewise same for beta 9.

> > curiously, for me anyhow, is that the deformation changes depending on
> > orientation or camera view.
>
> Bounding boxes have that effect. Essentially your shape gets clipped in
> "image space" by the outline of the b'box, which changes shape as the
> b'box is viewed from different angles: Head-on it's a rectangle, while
> at other angles it changes into an irregular hexagon.

Makes sense now that you said it, and "bounding slabs" per the docs, I should
have obviously read that first. I get to thinking there might be fancy things
going on like sphere shapes for bounding being used automatically as well.

And I forget about the ability to show those bounding boxes too. Or so I
thought... hmmmm... doesn't Vista_Buffer=on or +UV do that?
Tried just now in v3.6.2, v3.7.0, v3.7.1-beta9 and v3.7.1-rc1, nothing seen of
bounding boxes in render window.

[clipka] Re: CSG Bounding box algorithm [3148 days 8 hours and 9 minutes ago]

Thu, 24 Aug 2017 08:48:26 GMT

Am 24.08.2017 um 03:04 schrieb omniverse:

> I was wondering about this after coming across something about the automatic
> bounding from the version 3.5 sample scene chess2.pov while rendering some of
> those old files.
...
> According to what is said here, I suppose that particular CSG object must be a
> problem due to the intersecting planes and quartics (infinite shapes).

Thanks for spotting this one.

Looks like the b'box computation for quadrics (sorry, not quartics; got
that wrong in the previous post) fails to respect the `inverse` keyword
for /some/ reason.

> And
> curiously, for me anyhow, is that the deformation changes depending on
> orientation or camera view.

Bounding boxes have that effect. Essentially your shape gets clipped in
"image space" by the outline of the b'box, which changes shape as the
b'box is viewed from different angles: Head-on it's a rectangle, while
at other angles it changes into an irregular hexagon.

[omniverse] Re: CSG Bounding box algorithm [3148 days 15 hours and 53 minutes ago]

Thu, 24 Aug 2017 01:05:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 23.08.2017 um 14:09 schrieb Bald Eagle:
> > Can anyone tell me if this is still the case?
> >
> > From (bottom of page):
> > http://www.povray.org/documentation/view/3.6.0/184/
> >
> > But this automatic bounding is not perfect. There are situations where a perfect
> > automatic bounding is very hard to calculate. One situation is the difference
> > and the intersection CSG operations. POV-Ray does what it can, but sometimes it
> > makes a pretty poor job. This can be specially seen when the resulting CSG
> > object is very small compared to the CSG member objects.
--->8---
> > This didn't seem to me to be a factual representation - I believe there are some
> > straightforward algorithms for determining the bounding box of the intersection
> > for any two overlapping axis-aligned bounding boxes (AABB).
> > Am I wrong?
>
> Eyeballing the axis-aligned bounding box of an intersection as the
> intersection of the children's axis-aligned bounding boxes is indeed
> trivial, and that's why POV-Ray already does exactly that by default.
>
> (*Well, not /totally/ exactly: When planes or quartics are involved,
> POV-Ray tries to come up with tighter bounds for them by using the
> b'boxes of the sibling objects as constraints.)
>
> The problem hinted at by the docs is that sometimes this simple
> algorithm gives you a bounding box far larger than necessary, and in
> such cases providing a "hand-made" bounding box will increase rendering
> speed.
>
> There is no generic algorithm to compute the exact b'box of an
> intersection. Each specific combination of primitives would need its own
> algorithm.
---8<---
> > If this is still an issue, are there certain cases that are especially
> > problematic for certain CSG operations?
>
> Yes: All cases and none at all. Almost /any/ combination of primitives
> can be used to come up with pathological cases.

Interesting, as usual.

I was wondering about this after coming across something about the automatic
bounding from the version 3.5 sample scene chess2.pov while rendering some of
those old files.
Chess2 uses quartics and I changed them to isosurfaces, cone and cylinder for
the various shapes some time ago when I modified it for version 3.7.

Except for the Rook chess piece, removal of the manual bounding appears okay on
all other pieces, and the reason I remember commenting that out for v3.5 was
because of improvements for automatic bounding made back then.
You know, progress; so was thinking move ahead and leave manual bounding behind
if at all possible.

No idea how the malformed Rook was overlooked, if it always was, and I'm unable
to run version 3.5 right now to check on it from there so I can only look at it
from 3.7 with version setting of 3.5. At least the bounded_by { sphere { <0, 5,
0>, 5.831 } } is still there allowing uncommenting as a fix.

According to what is said here, I suppose that particular CSG object must be a
problem due to the intersecting planes and quartics (infinite shapes). And
curiously, for me anyhow, is that the deformation changes depending on
orientation or camera view. From chess2.pov:

#version 3.5;

#include "shapes.inc"

#declare Cylinder_Y =
 quadric
  {<1, 0, 1>,
   <0, 0, 0>,
   <0, 0, 0>, -1
  }

#declare Rook = union {
   intersection {
      union {
         plane { +x, -0.5 }
         plane { -x, -0.5 }
         plane { y, 9 }
      }

      union {
         plane { +z, -0.5 }
         plane { -z, -0.5 }
         plane { y, 9 }
      }

      plane { y, 10 }
      object { Cylinder_Y scale <2, 1, 2> }
      object { Cylinder_Y scale <1.2, 1, 1.2> inverse }
      plane { -y, -8 }
   }

   intersection {
      plane { y, 8 }
      object { Hyperboloid_Y
         scale <1, 1.5, 1>
         translate 5.401924*y
      }
      plane { -y, -3 }
   }

   sphere { <0, 0, 0>, 1
      scale <2.5, 0.5, 2.5>
      translate 2.8*y
   }

//   object { PieceBase }
}

#declare WRook = object {
   Rook

   // bounded_by { sphere { <0, 5, 0>, 5.831 } }

   texture {
     // WWood
      pigment { rgb 1 }
   }
}

object {
    WRook
   // rotate <-90,90,0>/2 // change shape?
}

light_source {<10,100,-100>,1}
camera {location <0,6,-18>}

[clipka] Re: CSG Bounding box algorithm [3148 days 22 hours and 42 minutes ago]

Wed, 23 Aug 2017 18:15:53 GMT

Am 23.08.2017 um 14:09 schrieb Bald Eagle:
> Can anyone tell me if this is still the case?
> 
> From (bottom of page):
> http://www.povray.org/documentation/view/3.6.0/184/
> 
> But this automatic bounding is not perfect. There are situations where a perfect
> automatic bounding is very hard to calculate. One situation is the difference
> and the intersection CSG operations. POV-Ray does what it can, but sometimes it
> makes a pretty poor job. This can be specially seen when the resulting CSG
> object is very small compared to the CSG member objects. For example:
> intersection
> { sphere { <-1000,0,0>,1001 }
>   sphere { <1000,0,0>,1001 }
> }
> (This is the same as making a difference with the second sphere inversed)
> In this example the member objects extend from <-2001,-1001,-1001> to
> <2001,1001,1001> although the resulting CSG object is a pretty small lens-shaped
> object which is only 2 units wide in the x direction and perhaps 10 or 20 or
> something wide in the y and z directions. As you can see, it is very difficult
> to calculate the actual dimensions of the object (but not impossible).
> In this type of cases POV-Ray makes a huge bounding box which is useless. You
> should bound this kind of objects by hand (specially when the it has lots of
> member objects). This can be done with the bounded_by keyword.
> 
> ---------------------------------------------
> 
> This didn't seem to me to be a factual representation - I believe there are some
> straightforward algorithms for determining the bounding box of the intersection
> for any two overlapping axis-aligned bounding boxes (AABB).
> Am I wrong?

Eyeballing the axis-aligned bounding box of an intersection as the
intersection of the children's axis-aligned bounding boxes is indeed
trivial, and that's why POV-Ray already does exactly that by default.

(*Well, not /totally/ exactly: When planes or quartics are involved,
POV-Ray tries to come up with tighter bounds for them by using the
b'boxes of the sibling objects as constraints.)

The problem hinted at by the docs is that sometimes this simple
algorithm gives you a bounding box far larger than necessary, and in
such cases providing a "hand-made" bounding box will increase rendering
speed.

There is no generic algorithm to compute the exact b'box of an
intersection. Each specific combination of primitives would need its own
algorithm.

> The only tricky part was getting it handle cases outside of Quadrant I, but I
> just implemented a faux-translation of the union {} of the two bounding boxes to
> place its min_extent at the origin. (I add in that correction vector for the
> intermediate calculations)

??? Why would you need special handling for the quadrants?

To compute the intersection of multiple axis-aligned b'boxes, all you
need to do is get the highest low bounds for all axes and the lowest
high bound for all axes.

> If this is still an issue, are there certain cases that are especially
> problematic for certain CSG operations?

Yes: All cases and none at all. Almost /any/ combination of primitives
can be used to come up with pathological cases.

[Mr] Re: Pause and resume PovRay from Gui Extension L... [3149 days 2 hours and 53 minutes ago]

Wed, 23 Aug 2017 14:05:01 GMT

"Henrik" <ter### [at] livedk> wrote:
> I have discovered that it its not possible to pause and resume rendering, from a
> GuiExtension library (Version 3.62). Will this possible in the new version?

From what I read around here, the GuiExtension library is searching for a
maintainer. I don't have the required skill set, but really hope you or anyone
could be interested, because in the long run doing a pov exporter only with
interpreted languages and the POV-Ray parser being run after export don't help
pov shine, speedwise, compared to alternatives.

[Bald Eagle] CSG Bounding box algorithm [3149 days 4 hours and 48 minutes ago]

Wed, 23 Aug 2017 12:10:01 GMT

Can anyone tell me if this is still the case?

From (bottom of page):
http://www.povray.org/documentation/view/3.6.0/184/

But this automatic bounding is not perfect. There are situations where a perfect
automatic bounding is very hard to calculate. One situation is the difference
and the intersection CSG operations. POV-Ray does what it can, but sometimes it
makes a pretty poor job. This can be specially seen when the resulting CSG
object is very small compared to the CSG member objects. For example:
intersection
{ sphere { <-1000,0,0>,1001 }
  sphere { <1000,0,0>,1001 }
}
(This is the same as making a difference with the second sphere inversed)
In this example the member objects extend from <-2001,-1001,-1001> to
<2001,1001,1001> although the resulting CSG object is a pretty small lens-shaped
object which is only 2 units wide in the x direction and perhaps 10 or 20 or
something wide in the y and z directions. As you can see, it is very difficult
to calculate the actual dimensions of the object (but not impossible).
In this type of cases POV-Ray makes a huge bounding box which is useless. You
should bound this kind of objects by hand (specially when the it has lots of
member objects). This can be done with the bounded_by keyword.

---------------------------------------------

This didn't seem to me to be a factual representation - I believe there are some
straightforward algorithms for determining the bounding box of the intersection
for any two overlapping axis-aligned bounding boxes (AABB).
Am I wrong?

I worked out some (messy but fully functional) code to do this, and it appears
to handle the few typical cases that I tested it with.

The only tricky part was getting it handle cases outside of Quadrant I, but I
just implemented a faux-translation of the union {} of the two bounding boxes to
place its min_extent at the origin. (I add in that correction vector for the
intermediate calculations)

If this is still an issue, are there certain cases that are especially
problematic for certain CSG operations?
Could we develop this into a small, fast part of the POV-Ray source code?


Thanks

[clipka] Re: code cleanup [3156 days 18 hours and 20 minutes ago]

Tue, 15 Aug 2017 22:37:41 GMT

Am 15.08.2017 um 21:51 schrieb hexcoder:

> [libraries/tiff/libtiff/tif_ojpeg.c:925]: (error) Invalid number of character
> '(' when these macros are defined: 'C_LOSSLESS_SUPPORTED;OJPEG_SUPPORT;never'.
...
> [libraries/tiff/contrib/stream/tiffstream.cpp:117]: (error) Uninitialized
> variable: ostr
...
> [libraries/tiff/tools/tiffsplit.c:64]: (error) Buffer overrun possible for long
> command line arguments.

This is libtiff, a 3rd party library. We won't be doing code cleanup in
there.


> [source/base/povmscpp.cpp:1757]: (error) Memory leak: nodeptr
...
> [source/base/povmscpp.cpp:1781]: (error) Memory leak: nodeptr

Thorsten commented on those already.


> [windows/cmedit/ccodemax.cpp:289]:
> [windows/cmedit/ccodemax.cpp:305]:
> [windows/cmedit/ccodemax.cpp:321]:
> [windows/cmedit/ccodemax.cpp:685]:
> [windows/cmedit/ccodemax.cpp:699]:
> The return value of malloc() should be checked before usage.

This is helper code for integrating CodeMax, a 3rd party library
providing the editor component for the Windows GUI. As we hope to get
rid of that component at the next possible opportunity (it doesn't fit
neatly with our current license), we probably won't be doing much code
cleanup in there either.

[Thorsten Froehlich] Re: code cleanup [3156 days 20 hours and 8 minutes ago]

Tue, 15 Aug 2017 20:50:01 GMT

"hexcoder" <nomail@nomail> wrote:
>
> [source/base/povmscpp.cpp:1757]: (error) Memory leak: nodeptr
>
> In case of an exception nodeptr cannot be freed anymore...
>
> [source/base/povmscpp.cpp:1781]: (error) Memory leak: nodeptr
>
> In case of an exception nodeptr cannot be freed anymore...
>
> In both cases could
>
>  err = POVMS_InstallReceiver(context, ReceiveHandler, hclass, hid, (void
> *)this);
>  if(err != pov_base::kNoErr)
>   throw POV_EXCEPTION_CODE(err);
>
> be moved to the beginning of the method? I see no dependency to local variables
> here.

No. This exception will always have to be a fatal error for the application
because if is more or less an emergency exit when POV-Ray runs out of memory. So
it is too late the fiddle with memory anyway. Basically all POVMS errors are
fatal because it means communication within POV-Ray's threads is broken, in
which case you actually "leak" whole threads...

[hexcoder] code cleanup [3156 days 21 hours and 3 minutes ago]

Tue, 15 Aug 2017 19:55:01 GMT

Hi,
i just ran cppcheck for povray sources:

[libraries/tiff/libtiff/tif_ojpeg.c:925]: (error) Invalid number of character
'(' when these macros are defined: 'C_LOSSLESS_SUPPORTED;OJPEG_SUPPORT;never'.

ok, 'never' should obviously never be defined, otherwise it would not compile.

[libraries/tiff/contrib/stream/tiffstream.cpp:117]: (error) Uninitialized
variable: ostr

 ostream* ostr;
 if(ts->m_outStream != NULL) {
     ostr = ts->m_outStream;
 } else if(ts->m_ioStream != NULL) {
     ostr = ts->m_ioStream;
 }

 streampos start = ostr->tellp();

Here another else branch would be good in order to handle the case of
ts->m_outStream == NULL and ts->m_ioStream == NULL
(if that is possible (who knows))

[libraries/tiff/tools/tiffsplit.c:64]: (error) Buffer overrun possible for long
command line arguments.

might be triggered from the outside, if tiffsplit is used at all.


[source/base/povmscpp.cpp:1757]: (error) Memory leak: nodeptr

In case of an exception nodeptr cannot be freed anymore...

[source/base/povmscpp.cpp:1781]: (error) Memory leak: nodeptr

In case of an exception nodeptr cannot be freed anymore...

In both cases could

 err = POVMS_InstallReceiver(context, ReceiveHandler, hclass, hid, (void
*)this);
 if(err != pov_base::kNoErr)
  throw POV_EXCEPTION_CODE(err);

be moved to the beginning of the method? I see no dependency to local variables
here.

[windows/cmedit/ccodemax.cpp:289]:
[windows/cmedit/ccodemax.cpp:305]:
[windows/cmedit/ccodemax.cpp:321]:
[windows/cmedit/ccodemax.cpp:685]:
[windows/cmedit/ccodemax.cpp:699]:
The return value of malloc() should be checked before usage.

Hope you find that useful, best regards Heiko

[Benjamin Chambers] Re: Port of FS85 - Aspect ratio issues #284 [3210 days 18 hours and 57 minutes ago]

Thu, 22 Jun 2017 22:00:48 GMT

On 6/22/2017 2:41 PM, clipka wrote:
> In an ideal world, I think we would have a means to specify the aspect
> ratio in the scene file, and specify only the horizontal or vertical
> resolution via INI or command-line parameters, and have the other
> dimension computed automatically.

Thinking about it more, I think I'd be in agreement with this method. 
More precisely, let user specify 2 pieces of information out of width, 
height, and aspect ratio for the viewport.

On the rendering end, you could either specify just the width/height 
(and use the default for the others from the scene), or you could 
specify both width/height to override the scene-specified aspect ratio.

[Benjamin Chambers] Re: Port of FS85 - Aspect ratio issues #284 [3210 days 19 hours and 23 minutes ago]

Thu, 22 Jun 2017 21:34:40 GMT

On 6/22/2017 2:41 PM, clipka wrote:
> Am 22.06.2017 um 21:15 schrieb Benjamin Chambers:
>> the image size. I honestly don't see how any further change is necessary.
> 
> Well, you may not, but others do.

Which is why I like to ask :D

> The current mechanism is fine as long as the person running the render
> is fully aware of the aspect ratio the scene was designed for, or the
> final resolution is explicitly specified in an INI file.

Honestly, I think this is one of those things where expecting the user 
to be aware is perfectly reasonable. There are somethings you want to 
simplify, but there are times when it's OK to say "You need to be at 
least <this> smart to use this product."

[clipka] Re: Port of FS85 - Aspect ratio issues #284 [3210 days 20 hours and 16 minutes ago]

Thu, 22 Jun 2017 20:41:38 GMT

Am 22.06.2017 um 21:15 schrieb Benjamin Chambers:
> https://github.com/POV-Ray/povray/issues/284
> 
> I have to say, I think this issue just needs to be closed out.
> 
> The current behavior allows the scene file to specify the viewport, and
> the INI file to specify the image size. The aspect ratio is implicit in
> the image size. I honestly don't see how any further change is necessary.

Well, you may not, but others do.

The current mechanism is fine as long as the person running the render
is fully aware of the aspect ratio the scene was designed for, or the
final resolution is explicitly specified in an INI file.

The mechanism has its shortcomings however, if the person running the
render is unaware of the intended aspect ratio, and the original author
did not fix the resolution via an INI file.


In an ideal world, I think we would have a means to specify the aspect
ratio in the scene file, and specify only the horizontal or vertical
resolution via INI or command-line parameters, and have the other
dimension computed automatically.

[Benjamin Chambers] Port of FS85 - Aspect ratio issues #284 [3210 days 21 hours and 42 minutes ago]

Thu, 22 Jun 2017 19:15:38 GMT

https://github.com/POV-Ray/povray/issues/284

I have to say, I think this issue just needs to be closed out.

The current behavior allows the scene file to specify the viewport, and 
the INI file to specify the image size. The aspect ratio is implicit in 
the image size. I honestly don't see how any further change is necessary.

Plus, there hasn't been any discussion on this in several years.

[Le Forgeron] Re: Widening Sin() function [3262 days 21 hours and 37 minutes ago]

Mon, 1 May 2017 19:20:36 GMT

Le 01/05/2017 Ã  20:26, Bald Eagle a Ã©crit :
> Posting this here for lack of a better place.
> 
> I'm interested in widening the output of a sin() trace - using POV-Ray to
> generate output for SVG which then gets processed into ... something else
> (G-Code I think)
> 
> So I thought maybe doing a simple "circle-sweep" would do it, though it may be
> overly complicated on the device end.
> Doing a line segment sweep with lines normal to the sine wave might do it, but
> may still be overly complicated.
> 
> Stacking sin waves of different frequencies and amplitudes to offset to the
> sides / top / bottom  seemed the way to go.
> 
> I was wondering is anyone had any suggestions as to how to code that up.
> 
> 
> 
If I got it right, you want a path that follow a sinus function, with
probably a constant width.

Remember that the derivative of sin(x) is +cos(x), so to widen y = sin
(x), you could adjust the coordinates of the point to plot.

For an amplitude A of the sin(), the width W of the ribbon should be a
fraction of A.

You could use some (u,v) to (x,y,z) transformation with isosurface or
parametric

u: as you want (0 to 2 pi, for one run)
v: -1 to 1

x: u+W.cos(u)*v
y: A.sin(u)+W.sin(u)*v
z: 0

[Bald Eagle] Widening Sin() function [3262 days 22 hours and 28 minutes ago]

Mon, 1 May 2017 18:30:01 GMT

Posting this here for lack of a better place.

I'm interested in widening the output of a sin() trace - using POV-Ray to
generate output for SVG which then gets processed into ... something else
(G-Code I think)

So I thought maybe doing a simple "circle-sweep" would do it, though it may be
overly complicated on the device end.
Doing a line segment sweep with lines normal to the sine wave might do it, but
may still be overly complicated.

Stacking sin waves of different frequencies and amplitudes to offset to the
sides / top / bottom  seemed the way to go.

I was wondering is anyone had any suggestions as to how to code that up.

[Benjamin Chambers] Re: Small update on the state of GPGPU [3355 days 22 hours and 26 minutes ago]

Sat, 28 Jan 2017 18:31:56 GMT

On 1/26/2017 1:08 PM, clipka wrote:
 > Am 26.01.2017 um 19:51 schrieb William F Pokorny:
 >
 >> One of the places I've wondered if we might sneak a look at GPUs near
 >> term would be as one or more, new internal functions for use with
 >> isosurfaces. Specifically isosurfaces needing to evaluate a great many
 >> functions for each evaluation - something not practical today.
 >
 > If the "sub-functions", as I would like to call them, are different in
 > structure (or even if their common structure can't be easily identified
 > as such), I suspect that's not a scenario where a GPGPU can help much.
 >

It's certainly possible; there are frameworks out there (CudaDNN, CNTK, 
and TensorFlow all come to mind, because of the projects I've been 
working on) that all take scripted input and run the final function on 
the GPU.

I suspect the above frameworks have pre-defined shaders for various 
common functions, and merely pass the data between them based on your 
script. However, it would be entirely possible to compile iso functions 
into shader code (Cuda C or the equivalent in OpenCL) and let the driver 
load it onto the GPU for you.

But it wouldn't be worth it, unless you can solve the first problem I 
posted in my original post: generating a situation where you have a 
cache of at least 100 (preferably 200 or more) function calls.

[Benjamin Chambers] Re: Small update on the state of GPGPU [3355 days 22 hours and 27 minutes ago]

Sat, 28 Jan 2017 18:30:19 GMT

On 1/26/2017 1:08 PM, clipka wrote:
> Am 26.01.2017 um 19:51 schrieb William F Pokorny:
>
>> One of the places I've wondered if we might sneak a look at GPUs near
>> term would be as one or more, new internal functions for use with
>> isosurfaces. Specifically isosurfaces needing to evaluate a great many
>> functions for each evaluation - something not practical today.
>
> If the "sub-functions", as I would like to call them, are different in
> structure (or even if their common structure can't be easily identified
> as such), I suspect that's not a scenario where a GPGPU can help much.
>

It's certainly possible; there are frameworks out there (CudaDNN, CNTK, 
and TensorFlow all come to mind, because of the projects I've been 
working on) that all take scripted input and run the final function on 
the GPU.

I suspect the above frameworks have pre-defined shaders for various 
common functions, and merely pass the data between them based on your 
script. However, it would be entirely possible to compile iso functions 
into shader code (Cuda C or the equivalent in OpenCL) and let the driver 
load it onto the GPU for you.

But it wouldn't be worth it, unless you can solve the first problem I 
posted in my original post: generating a situation where you have a 
cache of at least 100 (preferably 200 or more) function calls.

[William F Pokorny] Re: Small update on the state of GPGPU [3357 days 17 hours and 10 minutes ago]

Thu, 26 Jan 2017 23:48:13 GMT

On 01/26/2017 03:08 PM, clipka wrote:
> Am 26.01.2017 um 19:51 schrieb William F Pokorny:
>
> If the "sub-functions", as I would like to call them, are different in
> structure (or even if their common structure can't be easily identified
> as such), I suspect that's not a scenario where a GPGPU can help much.
>
I agree.

It was the point list as function-origins idea (the voronoi-ish results 
I posted a year or so ago) I had foremost in mind. In other words there 
would be many of the same function each with a unique origin in the 
simplest case. Perhaps to narrow an application practically, but as 
something with which to experiment with GPUs maybe OK...

Bill P.

[clipka] Re: Small update on the state of GPGPU [3357 days 20 hours and 49 minutes ago]

Thu, 26 Jan 2017 20:08:24 GMT

Am 26.01.2017 um 19:51 schrieb William F Pokorny:

> One of the places I've wondered if we might sneak a look at GPUs near
> term would be as one or more, new internal functions for use with
> isosurfaces. Specifically isosurfaces needing to evaluate a great many
> functions for each evaluation - something not practical today.

If the "sub-functions", as I would like to call them, are different in
structure (or even if their common structure can't be easily identified
as such), I suspect that's not a scenario where a GPGPU can help much.

[William F Pokorny] Re: Small update on the state of GPGPU [3357 days 22 hours and 6 minutes ago]

Thu, 26 Jan 2017 18:51:40 GMT

On 01/23/2017 12:06 PM, Benjamin Chambers wrote:
> On 1/23/2017 9:24 AM, Benjamin Chambers wrote:
>> If POV-Ray ever gets a re-write from scratch, it might happen.
>> Otherwise, the current method seems fine.
>
> Alternatively, we could try implementing it for very specific cases.
>
> For instance, running hit tests against objects... If you have an area
> light, you could run large arrays of hit tests (16x16 or larger would
> probably benefit from this) against individual objects to see if they
> obscure the light source.
>
> Also, as a first pass on the scene, you could run hit tests against
> every single object, and generate a map of the intersections.
>
> Both of those would, of course, be run AFTER bounding-box tests, to skip
> objects entirely.
>
Thanks for posting your experience.

One of the places I've wondered if we might sneak a look at GPUs near 
term would be as one or more, new internal functions for use with 
isosurfaces. Specifically isosurfaces needing to evaluate a great many 
functions for each evaluation - something not practical today.

Last I looked for my Ubuntu platform (14.04), OpenCL looked messy to 
install and run. I bailed before attempting anything!

Bill P.

[Benjamin Chambers] Re: Small update on the state of GPGPU [3360 days 23 hours and 51 minutes ago]

Mon, 23 Jan 2017 17:06:27 GMT

On 1/23/2017 9:24 AM, Benjamin Chambers wrote:
> If POV-Ray ever gets a re-write from scratch, it might happen.
> Otherwise, the current method seems fine.

Alternatively, we could try implementing it for very specific cases.

For instance, running hit tests against objects... If you have an area 
light, you could run large arrays of hit tests (16x16 or larger would 
probably benefit from this) against individual objects to see if they 
obscure the light source.

Also, as a first pass on the scene, you could run hit tests against 
every single object, and generate a map of the intersections.

Both of those would, of course, be run AFTER bounding-box tests, to skip 
objects entirely.

[Benjamin Chambers] Small update on the state of GPGPU [3361 days and 33 minutes ago]

Mon, 23 Jan 2017 16:24:24 GMT

Yes, I know, POV-Ray wouldn't work well on the GPU. But every now and 
then, someone asks about it and, since I've been doing some side 
projects with CUDA, I thought I'd put down here what would actually be 
necessary for it to be useful.

First off, there is a huge latency hit when moving data between the CPU 
and the GPU. This right here is the largest problem; it's simply faster 
to use the CPU for many applications because your data size isn't large 
enough.

In my own experiments, for a simple multiply-add, you need roughly 200 
operations for it to be worthwhile.
Going into more detail, I have a laptop with a dual-core I5 running at 
3GHz, and a mobile GTX 860 video card (640 CUDA cores). With these two 
processors, I found a speed parity at 187 data items. Again, this was a 
simple multiply-add using floating point values. If you're doing 
anything more complex, it will lower the number necessary; if you're 
using double precision, it will increase the number of items needed.

The take-away is that, unless you are performing the same operation on 
about 200 items, it will be faster to run it on the CPU than to use the GPU.

The upside though is that the other previous objections (general purpose 
programmability, support for double-precision, etc) have basically all 
been overcome. With CUDA, OpenCL, and Vulkan available GPUs are easy 
enough to program to actually put POV's functions on consumer level GPUs.

What would be necessary, then, for this to be useful for POV-Ray is for 
POV to cache function calls in sufficient numbers. The caching mechanism 
itself would probably add some overhead, as would switching shader 
cores, but with large image sizes it is conceivable that enough calls 
could be cached to make it worthwhile. It would be a massive amount of 
work in re-writing POV, though.

If POV-Ray ever gets a re-write from scratch, it might happen. 
Otherwise, the current method seems fine.

[LanuHum] Re: Interested in CMake support (build system, I... [3453 days 7 hours and 48 minutes ago]

Sun, 23 Oct 2016 09:10:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 22.10.2016 um 12:42 schrieb LanuHum:
> > For example, the structure is different from the master and hgpovray.
> > Now I understand why stupid written configuration files gnumake.
> > CMakeListsGenerator.py
>
> So instead of an Automake script we'd get a Python script?
>
> I'm not sure if this is really a win -- most notably since Automake does
> a lot more than just determine what files to compile and what libraries
> to link, such as detecting whether particular semi-standard include
> files, data types or functions are available (defining all those
> HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
> code).

I do not reinvent the wheel. I just do not know Automake, but need to build the
program. I do not know where I have to write the changes to be included in your
project my files. I found a solution to the primitive, but it works.

My posts on this thread are just an idea.
Someone might want to develop it.
The source code of the blender always had several options for building:
cmake, make and scons.
Scons uses python.

:)

[clipka] Re: Interested in CMake support (build system, I... [3453 days 18 hours and 21 minutes ago]

Sat, 22 Oct 2016 22:36:32 GMT

Am 22.10.2016 um 12:42 schrieb LanuHum:
> For example, the structure is different from the master and hgpovray.
> Now I understand why stupid written configuration files gnumake.
> CMakeListsGenerator.py

So instead of an Automake script we'd get a Python script?

I'm not sure if this is really a win -- most notably since Automake does
a lot more than just determine what files to compile and what libraries
to link, such as detecting whether particular semi-standard include
files, data types or functions are available (defining all those
HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
code).

[LanuHum] Re: Interested in CMake support (build system, I... [3454 days 6 hours and 13 minutes ago]

Sat, 22 Oct 2016 10:45:00 GMT

For example, the structure is different from the master and hgpovray.
Now I understand why stupid written configuration files gnumake.
CMakeListsGenerator.py

import os,sys

external_library = ['SDL','ILMBASE','OPENEXR','JPEG','PNG','TIFF']
pkg_modules = ['sdl','IlmBase','OpenEXR','libtiff-4']
cmake_names = ['SDL','ILMBASE','OPENEXR','TIFF']
cmake_packages = ['PkgConfig','JPEG','PNG']

cmakelist = open('CMakeLists.txt','w')
cmakelist.write('cmake_minimum_required(VERSION 2.8)\n\n')
cmakelist.write('project(povanim)\n\n')
if sys.platform in {'linux'}:
    cmakelist.write('set( CMAKE_CXX_FLAGS "-pipe -Wno-multichar \\\n')
    cmakelist.write('   -Wno-write-strings -fno-enforce-eh-specs \\\n')
    cmakelist.write('   -Wno-non-template-friend -s -O3 \\\n')
    cmakelist.write('   -ffast-math -march=native -pthread")\n\n')

sources = {}
unix_source_folders = {'source', 'platform', 'unix', 'vfe'}
win_source_folders = {'source', 'platform', 'windows', 'vfe'}
if sys.platform in {'linux'}:
    source_folders = unix_source_folders

if sys.platform[:3] == 'win':
    source_folders = win_source_folders
root_dir = os.getcwd()
root = root_dir.split('/')[-1]

prefix='POVRAY'

for folder in source_folders:
    source_key = folder.upper()
    source_key = prefix + '_' + source_key
    source_dir1 = os.path.join(root_dir,folder)
    value = source_dir1.split('/')
    plus = False
    source_value = ''
    for v in value:
        if v == root:
            plus = True
            continue
        if plus:
            source_value += v
            plus = False
    sources[source_key] = source_value
    src1 = os.listdir(source_dir1)
    for ob in src1:
        source_dir2 = os.path.join(source_dir1,ob)
        source_key1 = source_key
        if os.path.isdir(source_dir2):
            src2 = os.listdir(source_dir2)
            isCPP = False
            for ob1 in src2:
                if ob1.endswith('.cpp'):
                    isCPP = True
                    break
            if isCPP:
                source_key1 += ('_' + ob.upper())
                source_value1 = source_value
                source_value1 += ('/' + ob)
                sources[source_key1] = source_value1
                for ob1 in src2:
                    source_dir3 = os.path.join(source_dir2,ob1)
                    source_key2 = source_key1
                    if os.path.isdir(source_dir3):
                        src3 = os.listdir(source_dir3)
                        isCPP1 = False
                        for ob2 in src3:
                            if ob2.endswith('.cpp'):
                                isCPP1 = True
                                break
                        if isCPP1:
                            source_key2 += ('_' + ob1.upper())
                            source_value2 = source_value1
                            source_value2 += ('/' + ob1)
                            sources[source_key2] = source_value2
                        else:
                            continue
            else:
                continue

for i,k in enumerate(sources):
    cmakelist.write('set(%s    %s)\n'%(k,sources[k]))
cmakelist.write('\n\n')

for i,k in enumerate(sources):
    aux = k.replace('_','')
    cmakelist.write('aux_source_directory( ${%s}    %s)\n'%(k,aux))
cmakelist.write('\n\n')

for pack in cmake_packages:
    cmakelist.write('find_package(%s REQUIRED)\n'%pack)
cmakelist.write('\n\n')

for i,mod in enumerate(pkg_modules):
    cmake_name = mod.upper()
    cmakelist.write('pkg_search_module(%s REQUIRED %s)\n'%(cmake_names[i],mod))
cmakelist.write('\n\n')

cmakelist.write('include_directories(\n')
for i,k in enumerate(sources):
    aux = k.split('_')
    if len(aux) == 2:
        cmakelist.write('       ${%s}\n'%(k))
for lib in external_library:
    cmakelist.write('       ${%s_INCLUDE_DIRS}\n'%lib)
cmakelist.write(')\n')
cmakelist.write('\n\n')

cmakelist.write('add_executable(\n')
cmakelist.write('       ${PROJECT_NAME}\n')
for i,k in enumerate(sources):
    aux = k.replace('_','')
    cmakelist.write('       ${%s}\n'%(aux))
cmakelist.write(')\n')
cmakelist.write('\n\n')

cmakelist.write('target_link_libraries(\n')
cmakelist.write('       ${PROJECT_NAME}\n')

for lib in external_library:
    cmakelist.write('       ${%s_LIBRARIES}\n'%lib)
cmakelist.write('       -lz -lm boost_thread boost_system\n')
cmakelist.write(')\n')

cmakelist.close()

[Cousin Ricky] Re: solving polynomials [3454 days 12 hours and 43 minutes ago]

Sat, 22 Oct 2016 04:15:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Now, it only occurs for 5th and more order polynomial, something that is
> rarely seen.

I've used 8th order in the past, and there's a significant chance that I will
again in the future.

[clipka] Re: solving polynomials [3455 days 18 hours and 51 minutes ago]

Thu, 20 Oct 2016 22:07:00 GMT

Am 20.10.2016 um 20:13 schrieb Le_Forgeron:

> On second look, I'm not even sure the break is at the right place...
> Christoph ?

Dang. I think it indeed isn't.

[Le Forgeron] Re: solving polynomials [3455 days 22 hours and 45 minutes ago]

Thu, 20 Oct 2016 18:13:09 GMT

Le 20/10/2016 Ã  20:02, Le_Forgeron a Ã©crit :
> Le 20/10/2016 Ã  09:39, robfi680 a Ã©crit :
>> I was just looking at the source code for POVRay 3.7 for solving polynomials. In
>> the default case for Solve_Polynomial it looks to me like it solves the
>> polynomial twice for orders higher than four when a root is eliminated. I am
>> trying to understand the code for my own use. Could there be a break statement
>> missing ? Otherwise why does it solve for order n-1 and then n ?
>>
>> The code looks like:
>>   default:
>>
>>    if (epsilon > 0.0)
>>    {
>>     if ((c[n-1] != 0.0) && (fabs(c[n]/c[n-1]) < epsilon))
>>     {
>>      Thread->Stats()[Roots_Eliminated]++;
>>
>>      roots = polysolve(n-1, c, r);
>>     }
>>    }
>>
>>    /* Solve n-th order polynomial. */
>>
>>    roots = polysolve(n, c, r);
>>
>>    break;
>>
>>
>>
> 
> The interesting part is that master branch is already corrected : yes, a
> break is/was missing.
> 
> Now, it only occurs for 5th and more order polynomial, something that is
> rarely seen.
> 
> The correction was done on 8th September 2016, found by static code
> analysis.
> 

On second look, I'm not even sure the break is at the right place...
Christoph ?

            if (epsilon > 0.0)
            {
                if ((c[n-1] != 0.0) && (fabs(c[n]/c[n-1]) < epsilon))
                {
                    stats[Roots_Eliminated]++;

                    roots = polysolve(n-1, c, r);
                }

                break;
            }

            /* Solve n-th order polynomial. */

            roots = polysolve(n, c, r);

            break;

[Le Forgeron] Re: solving polynomials [3455 days 22 hours and 55 minutes ago]

Thu, 20 Oct 2016 18:02:44 GMT

Le 20/10/2016 Ã  09:39, robfi680 a Ã©crit :
> I was just looking at the source code for POVRay 3.7 for solving polynomials. In
> the default case for Solve_Polynomial it looks to me like it solves the
> polynomial twice for orders higher than four when a root is eliminated. I am
> trying to understand the code for my own use. Could there be a break statement
> missing ? Otherwise why does it solve for order n-1 and then n ?
> 
> The code looks like:
>   default:
> 
>    if (epsilon > 0.0)
>    {
>     if ((c[n-1] != 0.0) && (fabs(c[n]/c[n-1]) < epsilon))
>     {
>      Thread->Stats()[Roots_Eliminated]++;
> 
>      roots = polysolve(n-1, c, r);
>     }
>    }
> 
>    /* Solve n-th order polynomial. */
> 
>    roots = polysolve(n, c, r);
> 
>    break;
> 
> 
> 

The interesting part is that master branch is already corrected : yes, a
break is/was missing.

Now, it only occurs for 5th and more order polynomial, something that is
rarely seen.

The correction was done on 8th September 2016, found by static code
analysis.

[robfi680] solving polynomials [3456 days 9 hours and 18 minutes ago]

Thu, 20 Oct 2016 07:40:00 GMT

I was just looking at the source code for POVRay 3.7 for solving polynomials. In
the default case for Solve_Polynomial it looks to me like it solves the
polynomial twice for orders higher than four when a root is eliminated. I am
trying to understand the code for my own use. Could there be a break statement
missing ? Otherwise why does it solve for order n-1 and then n ?

The code looks like:
  default:

   if (epsilon > 0.0)
   {
    if ((c[n-1] != 0.0) && (fabs(c[n]/c[n-1]) < epsilon))
    {
     Thread->Stats()[Roots_Eliminated]++;

     roots = polysolve(n-1, c, r);
    }
   }

   /* Solve n-th order polynomial. */

   roots = polysolve(n, c, r);

   break;

[LanuHum] Re: Interested in CMake support (build system, I... [3466 days 20 hours and 8 minutes ago]

Sun, 9 Oct 2016 20:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 09.10.2016 um 11:57 schrieb LanuHum:
>
> > To build the project in Linux, I wrote a single file CMakeLists.txt
> ...
>
> > set( SOURCE_ROOT                    source )
> > set( SOURCE_BASKEND                 source/backend )
> > set( SOURCE_BASKEND_BOUNDING        source/backend/bounding )
> > set( SOURCE_BASKEND_CONTROL         source/backend/control )
> > set( SOURCE_BASKEND_LIGHTING        source/backend/lighting )
> > set( SOURCE_BASKEND_RENDER          source/backend/render )
> > set( SOURCE_BASKEND_SCENE           source/backend/scene )
> > set( SOURCE_BASKEND_SUPPORT         source/backend/support )
> ...
> Isn't that overly verbose? Can't CMake build the contents of an entire
> directory tree recursively?
>
> (I guess for your own project you're probably ok with this for now, but
> I'm also interested in exploring the potential of CMake for official
> POV-Ray, so since you're toying around with CMake anyway, I'd be
> grateful if you could investigate a bit further in that direction.)
>

My problem - poor understanding of English.
No information in Russian.
Russian-speaking programmers write in English.
I hardly found aux_source_directory. :)))))
Usually written CMakeLists.txt for each directory.
But I do not think a large file.
This is much less than: configure.in, configure.ac, makefile.in, prebuild.sh,
bootstrap, makefile and so on.
Yes, I got ready config.h and the source code has disabled some functions.
I need to understand more.

[clipka] Re: Interested in CMake support (build system, I... [3466 days 22 hours and 2 minutes ago]

Sun, 9 Oct 2016 18:56:03 GMT

Am 09.10.2016 um 11:57 schrieb LanuHum:

> To build the project in Linux, I wrote a single file CMakeLists.txt
...

> set( SOURCE_ROOT                    source )
> set( SOURCE_BASKEND                 source/backend )
> set( SOURCE_BASKEND_BOUNDING        source/backend/bounding )
> set( SOURCE_BASKEND_CONTROL         source/backend/control )
> set( SOURCE_BASKEND_LIGHTING        source/backend/lighting )
> set( SOURCE_BASKEND_RENDER          source/backend/render )
> set( SOURCE_BASKEND_SCENE           source/backend/scene )
> set( SOURCE_BASKEND_SUPPORT         source/backend/support )
...
Isn't that overly verbose? Can't CMake build the contents of an entire
directory tree recursively?

(I guess for your own project you're probably ok with this for now, but
I'm also interested in exploring the potential of CMake for official
POV-Ray, so since you're toying around with CMake anyway, I'd be
grateful if you could investigate a bit further in that direction.)


> fatal error: jversion.h: No such file or directory
>          #include <jversion.h>
...
> Povray does not use an external library libjpeg????
> jpeg-devel package has only these files:
>    /usr/include/jconfig.h
>    /usr/include/jerror.h
>    /usr/include/jmorecfg.h
>    /usr/include/jpegint.h
>    /usr/include/jpeglib.h
>    /usr/include/turbojpeg.h
>    /usr/lib64/libjpeg.so
>    /usr/lib64/libturbojpeg.so

Historically, POV-Ray has been using the contents of `jversion.h` to
determine the version of libjpeg it reports to the end user in the list
of library copyright notices.

This works fine with the Windows version, since it is linked to the
version of libjpeg we're distributing in source code format along with
the POV-Ray for Windows source code; but as you have noticed correctly,
the file is typically unavailable for Unix builds as our Unix build
process nowadays always relies on an external libjpeg (disabling JPEG if
such an external library is unavailable).

In our automake-based Unix build process, this has been worked around by
faking the file, with information obtained by the automake tools via
other means.


I had never investigated this before, but now that I've looked at it I
consider it a bug, or at least a flaw that should (and can) be fixed. I
suspect it might be some artifact from the history of libjpeg. After
all, POV-Ray is in some sense 5 years older than libjpeg, and there may
have been times when `jversion.h` used to be the only file from which
version information could be obtained.

All versions of libjpeg that POV-Ray is still compatible with appear to
provide version information in `jpeglib.h`, and I've just made sure
that's the source future versions of POV-Ray will get their version
information from.

[LanuHum] Re: Interested in CMake support (build system, I... [3467 days 3 hours and 28 minutes ago]

Sun, 9 Oct 2016 13:30:00 GMT

All very good. :)

leonid@lanucomp ~/workspace/programming/povray_animator/povray $ LC_ALL=C make
-j4
Scanning dependencies of target povray
[  0%] Building CXX object CMakeFiles/povanim.dir/source/pov_mem.cpp.o
.....
.....
[ 99%] Building CXX object CMakeFiles/povanim.dir/vfe/unix/vfeplatform.cpp.o
[100%] Linking CXX executable povray
[100%] Built target povray
leonid@lanucomp ~/workspace/programming/povray_animator/povray $

[LanuHum] Re: Interested in CMake support (build system, I... [3467 days 6 hours and 58 minutes ago]

Sun, 9 Oct 2016 10:00:00 GMT

In his project, I want to use the Povray. I can not study very long
configuration files.
I decided to use CMake.
To build the project in Linux, I wrote a single file CMakeLists.txt

cmake_minimum_required(VERSION 2.8)

project(povanim)


set(CMAKE_CXX_FLAGS "-std=c++11 -pipe -Wno-multichar -Wno-write-strings
-fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math -march=native
-pthread")


set( SOURCE_ROOT                    source )
set( SOURCE_BASKEND                 source/backend )
set( SOURCE_BASKEND_BOUNDING        source/backend/bounding )
set( SOURCE_BASKEND_CONTROL         source/backend/control )
set( SOURCE_BASKEND_LIGHTING        source/backend/lighting )
set( SOURCE_BASKEND_RENDER          source/backend/render )
set( SOURCE_BASKEND_SCENE           source/backend/scene )
set( SOURCE_BASKEND_SUPPORT         source/backend/support )
set( SOURCE_BASE                    source/base )
set( SOURCE_BASE_ANIMATION          source/base/animation )
set( SOURCE_BASE_FONT               source/base/font )
set( SOURCE_BASE_IMAGE              source/base/image )
set( SOURCE_CORE                    source/core )
set( SOURCE_CORE_BOUNDING           source/core/bounding )
set( SOURCE_CORE_COLOUR             source/core/colour )
set( SOURCE_CORE_LIGHTING           source/core/lighting )
set( SOURCE_CORE_MATERIAL           source/core/material )
set( SOURCE_CORE_MATH               source/core/math )
set( SOURCE_CORE_RENDER             source/core/render )
set( SOURCE_CORE_SCENE              source/core/scene )
set( SOURCE_CORE_SHAPE              source/core/shape )
set( SOURCE_CORE_SUPPORT            source/core/support )
set( SOURCE_FRONTEND                source/frontend )
set( SOURCE_PARSER                  source/parser )
set( SOURCE_POVMS                   source/povms )
set( SOURCE_VM                      source/vm )
set( SOURCE_UNIX                    unix )
set( SOURCE_PLATFORM_UNIX           platform/unix )
set( SOURCE_PLATFORM_X86            platform/x86)
set( SOURCE_VFE                     vfe )
set( SOURCE_VFE_UNIX                vfe/unix)


aux_source_directory( ${SOURCE_ROOT}                     SOURCEROOT )
aux_source_directory( ${SOURCE_BASKEND}                  SOURCEBASKEND )
aux_source_directory( ${SOURCE_BASKEND_BOUNDING}         SOURCEBASKENDBOUNDING )
aux_source_directory( ${SOURCE_BASKEND_CONTROL}          SOURCEBASKENDCONTROL )
aux_source_directory( ${SOURCE_BASKEND_LIGHTING}         SOURCEBASKENDLIGHTING )
aux_source_directory( ${SOURCE_BASKEND_RENDER}           SOURCEBASKENDRENDER )
aux_source_directory( ${SOURCE_BASKEND_SCENE}            SOURCEBASKENDSCENE )
aux_source_directory( ${SOURCE_BASKEND_SUPPORT}          SOURCEBASKENDSUPPORT )
aux_source_directory( ${SOURCE_BASE}                     SOURCEBASE )
aux_source_directory( ${SOURCE_BASE_ANIMATION}           SOURCEBASEANIMATION )
aux_source_directory( ${SOURCE_BASE_FONT}                SOURCEBASEFONT )
aux_source_directory( ${SOURCE_BASE_IMAGE}               SOURCEBASEIMAGE )
aux_source_directory( ${SOURCE_CORE}                     SOURCECORE )
aux_source_directory( ${SOURCE_CORE_BOUNDING}            SOURCECOREBOUNDING )
aux_source_directory( ${SOURCE_CORE_COLOUR}              SOURCECORECOLOUR )
aux_source_directory( ${SOURCE_CORE_LIGHTING}            SOURCECORELIGHTING )
aux_source_directory( ${SOURCE_CORE_MATERIAL}            SOURCECOREMATERIAL )
aux_source_directory( ${SOURCE_CORE_MATH}                SOURCECOREMATH )
aux_source_directory( ${SOURCE_CORE_RENDER}              SOURCECORERENDER )
aux_source_directory( ${SOURCE_CORE_SCENE}               SOURCECORESCENE )
aux_source_directory( ${SOURCE_CORE_SHAPE}               SOURCECORESHAPE )
aux_source_directory( ${SOURCE_CORE_SUPPORT}             SOURCECORESUPPORT )
aux_source_directory( ${SOURCE_FRONTEND}                 SOURCEFRONTEND )
aux_source_directory( ${SOURCE_PARSER}                   SOURCEPARSER )
aux_source_directory( ${SOURCE_POVMS}                    SOURCEPOVMS )
aux_source_directory( ${SOURCE_VM}                       SOURCEVM )
aux_source_directory( ${SOURCE_UNIX}                     SOURCEUNIX )
aux_source_directory( ${SOURCE_PLATFORM_UNIX}            SOURCEPLATFORMUNIX )
aux_source_directory( ${SOURCE_PLATFORM_X86}             SOURCEPLATFORMX86 )
aux_source_directory( ${SOURCE_VFE}                      SOURCEVFE )
aux_source_directory( ${SOURCE_VFE_UNIX}                 SOURCEVFEUNIX )

find_package(           JPEG REQUIRED)
find_package(           PNG REQUIRED)
find_package(           PkgConfig REQUIRED)

pkg_search_module(      SDL REQUIRED sdl)

set( UNIX_POVCONFIG_INCLUDE_DIR unix/povconfig)

include_directories(    ${SOURCE_ROOT}
                        ${SOURCE_BASKEND}
                        ${SOURCE_BASE}
                        ${SOURCE_CORE}
                        ${SOURCE_FRONTEND}
                        ${SOURCE_PARSER}
                        ${SOURCE_POVMS}
                        ${SOURCE_VM}
                        ${SOURCE_UNIX}
                        ${UNIX_POVCONFIG_INCLUDE_DIR}
                        ${SOURCE_PLATFORM_UNIX}
                        ${SOURCE_PLATFORM_X86}
                        ${SOURCE_VFE}
                        ${SOURCE_VFE_UNIX}
                        ${SDL_INCLUDE_DIRS}
                        ${JPEG_INCLUDE_DIRS}
                        ${PNG_INCLUDE_DIRS}
                        )

add_executable(         ${PROJECT_NAME}
                        ${SOURCEROOT}
                        ${SOURCEBASKEND}
                        ${SOURCEBASKENDBOUNDING}
                        ${SOURCEBASKENDCONTROL}
                        ${SOURCEBASKENDLIGHTING}
                        ${SOURCEBASKENDRENDER}
                        ${SOURCEBASKENDSCENE}
                        ${SOURCEBASKENDSUPPORT}
                        ${SOURCEBASE}
                        ${SOURCEBASEANIMATION}
                        ${SOURCEBASEFONT}
                        ${SOURCEBASEIMAGE}
                        ${SOURCECORE}
                        ${SOURCECOREBOUNDING}
                        ${SOURCECORECOLOUR}
                        ${SOURCECORELIGHTING}
                        ${SOURCECOREMATERIAL}
                        ${SOURCECOREMATH}
                        ${SOURCECORERENDER}
                        ${SOURCECORESCENE}
                        ${SOURCECORESHAPE}
                        ${SOURCECORESUPPORT}
                        ${SOURCEFRONTEND}
                        ${SOURCEPARSER}
                        ${SOURCEPOVMS}
                        ${SOURCEVM}
                        ${SOURCEUNIX}
                        ${SOURCEPLATFORMUNIX}
                        ${SOURCEPLATFORMX86}
                        ${SOURCEVFE}
                        ${SOURCEVFEUNIX}
                        )


target_link_libraries(  ${PROJECT_NAME}
                        ${SDL_LIBRARIES}
                        ${JPEG_LIBRARIES}
                        )

Not all external library I added, but JPEG FOUND

leonid@lanucomp ~/workspace/programming/povray_animator/povray $ LC_ALL=C make
Scanning dependencies of target povanim
[  0%] Building CXX object CMakeFiles/povanim.dir/source/pov_mem.cpp.o
[  1%] Building CXX object CMakeFiles/povanim.dir/source/povmain.cpp.o
[  1%] Building CXX object CMakeFiles/povanim.dir/source/backend/povray.cpp.o
/home/leonid/workspace/programming/povray_animator/povray-master/source/backend/povray.cpp:69:30:
fatal error: jversion.h: No such file or directory
         #include <jversion.h>
                              ^
compilation terminated.
CMakeFiles/povanim.dir/build.make:110: recipe for target
'CMakeFiles/povanim.dir/source/backend/povray.cpp.o' failed
make[2]: *** [CMakeFiles/povanim.dir/source/backend/povray.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/povanim.dir/all' failed
make[1]: *** [CMakeFiles/povanim.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
leonid@lanucomp ~/workspace/programming/povray_animator/povray $

In file povray.cpp:
    #ifndef LIBJPEG_MISSING
        #include <jversion.h>
    #endif

Povray does not use an external library libjpeg????
jpeg-devel package has only these files:
   /usr/include/jconfig.h
   /usr/include/jerror.h
   /usr/include/jmorecfg.h
   /usr/include/jpegint.h
   /usr/include/jpeglib.h
   /usr/include/turbojpeg.h
   /usr/lib64/libjpeg.so
   /usr/lib64/libturbojpeg.so

[clipka] Re: toFloat.h missing [3476 days 23 hours and 54 minutes ago]

Thu, 29 Sep 2016 17:03:17 GMT

Am 29.09.2016 um 10:28 schrieb Phane:
> Benjamin Chambers <ben### [at] outlookcom> wrote:
>> I finally got the custom build step to generate the header as needed.
>> I'm not sure which change made it, but what I did in the end to was to
>> create a new project file, set it to run after link (instead of
>> manifest), and set an Additional Dependency of $(TargetPath).
>>
>> We'll see as I work with the other header-generating projects which
>> change (or combination of them) was necessary.
> 
> Hi,
> please Benjamin can you share your MSVC15 Project ?
> I got same error plus some related to boost so if you have a working solution
> for MSVC2015 on windows x64 I'll like to try it

I would recommend trying a more recent version; The incompatibilities
with VS2015 have been ironed out in the master branch, and the VS2010
projects should build fine after auto-conversion.

[Phane] Re: toFloat.h missing [3477 days 8 hours and 28 minutes ago]

Thu, 29 Sep 2016 08:30:01 GMT

Benjamin Chambers <ben### [at] outlookcom> wrote:
> I finally got the custom build step to generate the header as needed.
> I'm not sure which change made it, but what I did in the end to was to
> create a new project file, set it to run after link (instead of
> manifest), and set an Additional Dependency of $(TargetPath).
>
> We'll see as I work with the other header-generating projects which
> change (or combination of them) was necessary.

Hi,
please Benjamin can you share your MSVC15 Project ?
I got same error plus some related to boost so if you have a working solution
for MSVC2015 on windows x64 I'll like to try it

regards
Stéphane

[clipka] Re: Parsing mesh2 data [3492 days 4 hours and 46 minutes ago]

Wed, 14 Sep 2016 12:12:10 GMT

Am 14.09.2016 um 11:57 schrieb Mr:
> "Mr" <nomail@nomail> wrote:
> 
>>
>> So there is not a single feature in mesh2 that we'd lose when switching to OBJ?
>> could we still use smoothing groups? no limit in the number of points/faces...?
>> Why did you choose it over some binary format like 3DS ? wouldn't this be even
>> faster?  maybe the partial update that could one day be implemented for
>> animations?
> I also forgot the current hack we use for vertex colors using pov pigments per
> vertex, will it still be possible?

No; the OBJ format does not support per-vertex colouring or per-vertex
texturing.

If your software of choice provides dedicated mesh2 output, then it is
certainly wise to stick to mesh2; the difference in speed is not that
impressive.

If on the other hand you would be using export to some other format
anyway, and convert to mesh2 from there without further processing, then
direct OBJ import is probably the way to go.

[clipka] Re: Parsing mesh2 data [3492 days 5 hours and 52 minutes ago]

Wed, 14 Sep 2016 11:06:08 GMT

Am 14.09.2016 um 11:45 schrieb Mr:

> So there is not a single feature in mesh2 that we'd lose when switching to OBJ?
> could we still use smoothing groups? no limit in the number of points/faces...?

mesh2 does not support smoothing groups; if the exporting program uses
them, it has to convert them to vertex normals (which are a much more
flexible mechanism) for mesh2 export; same deal for OBJ, so no loss there.

OBJ does not have an intrinsic limit to the number of vertices or faces;
exporters and imoporters may, and in fact there is /some/ upper limit
intrinsic in the new OBJ import code, but those limits are the same as
for the mesh2 parser, so no loss there either.


> Why did you choose it over some binary format like 3DS ? wouldn't this be even
> faster?  maybe the partial update that could one day be implemented for
> animations?

Compatibility and simplicity. OBJ is probably /the/ one and only
baseline mesh interchange format that /all/ mesh-based 3D tools support,
has a very straightforward structure, and besides is a text-based format
and thus can be read in an editor, which is an advantage in debugging.

3DS, on the other hand, has a rather complex nested structure, and also
has some other drawbacks; coincidently, those happen to include the very
topics you mentioned earlier:

- The format does not support explicit vertex normals, making it
necessary to fall back to smoothing groups instead; importing those into
POV-Ray would be a tremendous hassle, as POV-Ray internally operates
with vertex normals, which would have to be generated from the smoothing
groups, which in turn requires a costly look at neighboring triangles,
and may cost you more processing time than the binary import would save
you. Also, if the exporting program natively operates with vertex
normals as well, or uses a different algorithm to compute vertex normals
from smoothing groups for rendering, smoothing information will suffer
in the process.

- The format is limited to 65536 vertices and triangles per mesh.

Plus (though this would only be relevant when adding texture import):

- The format limits texture file names to 8.3 format (and without path
information I presume), requiring the exporter to copy the textures around.

[Mr] Re: Parsing mesh2 data [3492 days 6 hours and 58 minutes ago]

Wed, 14 Sep 2016 10:00:01 GMT

"Mr" <nomail@nomail> wrote:

>
> So there is not a single feature in mesh2 that we'd lose when switching to OBJ?
> could we still use smoothing groups? no limit in the number of points/faces...?
> Why did you choose it over some binary format like 3DS ? wouldn't this be even
> faster?  maybe the partial update that could one day be implemented for
> animations?
I also forgot the current hack we use for vertex colors using pov pigments per
vertex, will it still be possible?

[Mr] Re: Parsing mesh2 data [3492 days 7 hours and 8 minutes ago]

Wed, 14 Sep 2016 09:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 14.09.2016 um 10:08 schrieb Mr:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Fun fact:
> >>
> >> Trying to read obj files directly turns out to be only marginally faster
> >> than parsing mesh2 data (about 3% as it seems).
> >
> > Interesting! Too bad it's not alembic files which, as a caching format, will
> > probably benefit from a simpler/faster export flow...
>
> Uh, I'd rather not. With Alembic being a quite modern format, users may
> expect support for a few more features than just polygon meshes, such as
> NURBS and things, and supporting those would be a _lot_ of work. OBJ, on
> the other hand, is old enough that people know better than to expect
> such bells and whistles to work with all software.
>
> Also, I haven't yet found /any/ documentation whatsoever about the file
> format itself, only a ready-made library; so implementing even a tiny
> bit of it would require more than the mere ~500 lines of code I added
> for OBJ import; it may also suffer in speed from additional code
> required to convert the data structures provided by the library to those
> used by POV-Ray internally.
>
> > Still OBJ is interesting! do you think it would be worth exporting Blender mesh
> > geometry to OBJ instead of Mesh2 or rather let you investigate and optimize the
> > mesh2, so that it will then be even faster ! :-) ?
>
> When it comes to import speed, I would suspect OBJ to maintain a slight
> advantage over mesh2, because the formats are reasonably similar in
> structure, with OBJ being just that little bit less verbose(*). Mesh2
> parsing /per se/ cannot be reasonably sped up any further as it uses
> POV-Ray's general parser infrastructure (by contrast, OBJ import
> accesses the file directly; which also means that you can't generate OBJ
> data "on the fly" procedurally, like you can with mesh2 data, except by
> the tedious process of writing a temporary file). Any potential for
> speedup of mesh2 parsing is in pieces of code that OBJ import would also
> benefit from.
>
>
> (* Or at least it has the potential to be, if exporters group the
> triangles by material before writing them. If material changes
> frequently between consecutive triangles in the OBJ file, the format can
> get /very/ verbose.)

So there is not a single feature in mesh2 that we'd lose when switching to OBJ?
could we still use smoothing groups? no limit in the number of points/faces...?
Why did you choose it over some binary format like 3DS ? wouldn't this be even
faster?  maybe the partial update that could one day be implemented for
animations?

[clipka] Re: Parsing mesh2 data [3492 days 7 hours and 36 minutes ago]

Wed, 14 Sep 2016 09:21:17 GMT

Am 14.09.2016 um 10:08 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
>> Fun fact:
>>
>> Trying to read obj files directly turns out to be only marginally faster
>> than parsing mesh2 data (about 3% as it seems).
> 
> Interesting! Too bad it's not alembic files which, as a caching format, will
> probably benefit from a simpler/faster export flow...

Uh, I'd rather not. With Alembic being a quite modern format, users may
expect support for a few more features than just polygon meshes, such as
NURBS and things, and supporting those would be a _lot_ of work. OBJ, on
the other hand, is old enough that people know better than to expect
such bells and whistles to work with all software.

Also, I haven't yet found /any/ documentation whatsoever about the file
format itself, only a ready-made library; so implementing even a tiny
bit of it would require more than the mere ~500 lines of code I added
for OBJ import; it may also suffer in speed from additional code
required to convert the data structures provided by the library to those
used by POV-Ray internally.

> Still OBJ is interesting! do you think it would be worth exporting Blender mesh
> geometry to OBJ instead of Mesh2 or rather let you investigate and optimize the
> mesh2, so that it will then be even faster ! :-) ?

When it comes to import speed, I would suspect OBJ to maintain a slight
advantage over mesh2, because the formats are reasonably similar in
structure, with OBJ being just that little bit less verbose(*). Mesh2
parsing /per se/ cannot be reasonably sped up any further as it uses
POV-Ray's general parser infrastructure (by contrast, OBJ import
accesses the file directly; which also means that you can't generate OBJ
data "on the fly" procedurally, like you can with mesh2 data, except by
the tedious process of writing a temporary file). Any potential for
speedup of mesh2 parsing is in pieces of code that OBJ import would also
benefit from.

(* Or at least it has the potential to be, if exporters group the
triangles by material before writing them. If material changes
frequently between consecutive triangles in the OBJ file, the format can
get /very/ verbose.)

[clipka] Re: Parsing mesh2 data [3492 days 8 hours and 4 minutes ago]

Wed, 14 Sep 2016 08:54:07 GMT

Am 14.09.2016 um 09:46 schrieb Le_Forgeron:

>> I thought obj files had an ascii and binary version, but I was wrong.
>> That seems to be stl files. Maybe the binary stl format is faster to
>> read?
>>
>> https://en.wikipedia.org/wiki/STL_(file_format)
>>
> You can give it a try in hgpovray (there is a stl_load and stl_save )
> 
> https://github.com/LeForgeron/povray/wiki/Tesselation
> 
> The main issue with povray mesh import is the unique indexing of
> vectors: when the data structure is not like mesh2, each new component
> need to perform a search in previous values.

Ah, yes, and then there's that -- I totally forgot about that in
conjunction with STL. So OBJ will be faster anyway.

But I would put it the other way round: That's the main issue of naive
file formats which store triangles as a list of vertex coordinates,
rather than having a list of vertices and only storing vertex indices
per triangle.

That's absolutely not unique to POV-Ray; every sane piece of software
handling meshes does that internally. So exporting to a naive format and
re-importing is just a plain waste of time.

> Even the parsing of a mesh get slowed down as the number of triangles
> increased. Fast for 100, Normal when reaching 10 000, crawling after 1
> 000 000.

I guess some improvements could be made there. AFAIK the mesh code uses
a homebrew hash map for this purpose; large meshes may easily outgrow
the hash table, and a search tree would be more performant there.

But if speed is really of paramount importance, and memory not so much,
there's always the possibility of just storing duplicate vertices.

> Mesh2 avoid the search because the uniqueness is done before (by the
> generator of mesh2).

Not even by the generator of mesh2; the uniqueness is inherent in every
mesh editor that deserves the name (otherwise it would be a disconnected
triangle editor).

[clipka] Re: Parsing mesh2 data [3492 days 8 hours and 38 minutes ago]

Wed, 14 Sep 2016 08:19:18 GMT

Am 14.09.2016 um 08:39 schrieb scott:
>> Fun fact:
>>
>> Trying to read obj files directly turns out to be only marginally faster
>> than parsing mesh2 data (about 3% as it seems).
> 
> I thought obj files had an ascii and binary version, but I was wrong.
> That seems to be stl files. Maybe the binary stl format is faster to read?
> 
> https://en.wikipedia.org/wiki/STL_(file_format)

Faster to read maybe, but severely limited in functionality: The
official specification provides for nothing more than flat untextured
geometry.

Also, my guess would be that STL export is slightly less widespread than
OBJ export.


Besides, there are other things that bog down import; for instance, on
my system an import of two Gen.3 DAZ figures with hair takes about 11
seconds to load the image maps (and those are only the diffuse maps; the
exporter didn't even include specular maps or normal maps), some 3-4
seconds to actually load the mesh data, and another whopping 9 seconds
to build the internal bounding hierarchy (which can be suppressed with
"hierarchy off", but you absolutely positively don't want to do that,
/especially/ for big meshes)

[Mr] Re: Parsing mesh2 data [3492 days 8 hours and 48 minutes ago]

Wed, 14 Sep 2016 08:10:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Fun fact:
>
> Trying to read obj files directly turns out to be only marginally faster
> than parsing mesh2 data (about 3% as it seems).

Interesting! Too bad it's not alembic files which, as a caching format, will
probably benefit from a simpler/faster export flow...
Still OBJ is interesting! do you think it would be worth exporting Blender mesh
geometry to OBJ instead of Mesh2 or rather let you investigate and optimize the
mesh2, so that it will then be even faster ! :-) ?

[Le Forgeron] Re: Parsing mesh2 data [3492 days 9 hours and 11 minutes ago]

Wed, 14 Sep 2016 07:46:26 GMT

Le 14/09/2016 Ã  08:39, scott a Ã©crit :
>> Fun fact:
>>
>> Trying to read obj files directly turns out to be only marginally faster
>> than parsing mesh2 data (about 3% as it seems).
>
> I thought obj files had an ascii and binary version, but I was wrong.
> That seems to be stl files. Maybe the binary stl format is faster to read?
>
> https://en.wikipedia.org/wiki/STL_(file_format)
>
You can give it a try in hgpovray (there is a stl_load and stl_save )

https://github.com/LeForgeron/povray/wiki/Tesselation

The main issue with povray mesh import is the unique indexing of 
vectors: when the data structure is not like mesh2, each new component 
need to perform a search in previous values.

Even the parsing of a mesh get slowed down as the number of triangles 
increased. Fast for 100, Normal when reaching 10 000, crawling after 1 
000 000.

Mesh2 avoid the search because the uniqueness is done before (by the 
generator of mesh2).

[scott] Re: Parsing mesh2 data [3492 days 10 hours and 18 minutes ago]

Wed, 14 Sep 2016 06:39:14 GMT

> Fun fact:
>
> Trying to read obj files directly turns out to be only marginally faster
> than parsing mesh2 data (about 3% as it seems).

I thought obj files had an ascii and binary version, but I was wrong. 
That seems to be stl files. Maybe the binary stl format is faster to read?

https://en.wikipedia.org/wiki/STL_(file_format)

[clipka] Parsing mesh2 data [3492 days 18 hours and 37 minutes ago]

Tue, 13 Sep 2016 22:20:40 GMT

Fun fact:

Trying to read obj files directly turns out to be only marginally faster
than parsing mesh2 data (about 3% as it seems).

[clipka] Re: global settings in pre-scripted light defini... [3534 days 3 hours and 7 minutes ago]

Wed, 3 Aug 2016 13:51:09 GMT

Am 03.08.2016 um 13:13 schrieb Nieman:

> For creating images I use an pre-scripted textfile in which the light settings
> are definded.
> Now I need to setup some global settings which can not be setup within this
> file.
> The script of this file ist written below.
> Is there any way to define global settings within an .ini file. Or is there any
> command wihtin the script I can use. At my point of view it is not possible to
> define global setting in this file, because this commands are read after the
> model is rendered...

???
Maybe you could elaborate a bit on the workflow you are using, as I
don't think I completely understand what exactly you are doing.
(If you're struggling to explain it in English, feel free to explain it
in German instead.)

The only part I do understand is that you're using some other scripting
language (which one? I don't recognize it) to generate snippets of
POV-Ray scene code (how are they passed to POV-Ray itself?).

My first guess is that POV-Ray's `#include` statement is the key to
whatever you're trying to do.

[Nieman] global settings in pre-scripted light definitions [3534 days 5 hours and 43 minutes ago]

Wed, 3 Aug 2016 11:15:01 GMT

Hey all,

For creating images I use an pre-scripted textfile in which the light settings
are definded.
Now I need to setup some global settings which can not be setup within this
file.
The script of this file ist written below.
Is there any way to define global settings within an .ini file. Or is there any
command wihtin the script I can use. At my point of view it is not possible to
define global setting in this file, because this commands are read after the
model is rendered...

Thanks for any help!!


/////////////////////////////////////////////////////////////////



; MaxX=            240.0000
; MaxY=           0.0000000
; MaxZ=            500.0000
; MinX=           -260.0000
; MinY=           -400.0000
; MinZ=           0.0000000



CenterX = (MinX + MaxX) / 2.0
CenterY = (MinY + MaxY) / 2.0
CenterZ = (MinZ + MaxZ) / 2.0

CenterZ = CenterZ * -1.0  ; wegen POV hat KOS umgedreht
KameraZ = KameraZ * -1.0  ;
TargetZ = TargetZ * -1.0  ;


;Beispiel: Ein Spot links von der Scene plazieren ..




;SpotX = TargetX -400 ; // nach links
;SpotY = TargetY -6000;
;SpotZ = TargetZ;

Scene = 0;
n = 0
PovScene[Scene][0] = "Zwei Spots"            ; Erste zeile immer die
Definitionszeile




;Beispiel: Ein Spot rechts von der Scene plazieren .., aber ohne Schatten zu
werfen


SpotX = KameraX - 400
SpotY = KameraY - 6000
SpotZ = KameraZ




n = n+1
PovScene[Scene][n] = "light_source {  0*x   color rgb <1,1,1>    spotlight "
n = n+1
PovScene[Scene][n] = "translate <" + SpotX + "," + SpotY + "," + SpotZ + ">"
n = n+1
PovScene[Scene][n] = "point_at <" + CenterX + "," + CenterY + "," + CenterZ +
">"
n = n+1
PovScene[Scene][n] = "radius 180"
n = n+1
PovScene[Scene][n] = "tightness 50 "
n = n+1
PovScene[Scene][n] = "falloff 25"
n = n+1
PovScene[Scene][n] = "fade_distance 2000"
n = n+1
PovScene[Scene][n] = "fade_power 1"
n = n+1
PovScene[Scene][n] = "}"


;Beispiel: Ein Spot Mittig in der Scene plazieren



SpotX = CenterX
SpotY = MinY - 500
SpotZ = CenterZ

TargetX = TargetX -400;
TargetY = TargetY -6000

n = n+1
PovScene[Scene][n] = "light_source {  0*x   color rgb <1,1,1>    spotlight "
n = n+1
PovScene[Scene][n] = "translate <" + TargetX + "," + TargetY + "," + TargetZ +
">"
n = n+1
PovScene[Scene][n] = "point_at <" + CenterX + "," + CenterY + "," + CenterZ +
">"
n = n+1
PovScene[Scene][n] = "radius 180"
n = n+1
PovScene[Scene][n] = "tightness 50 "
n = n+1
PovScene[Scene][n] = "falloff 25"
n = n+1
PovScene[Scene][n] = "fade_distance 2000"
n = n+1
PovScene[Scene][n] = "fade_power 1"
n = n+1
PovScene[Scene][n] = "}"



Scene = Scene + 1

PovScene[Scene][0] = "Von der Kamera aus mit großem Spot"
PovScene[Scene][1] = "light_source {  0*x   color rgb <1,1,1>    spotlight
fade_power 10"
PovScene[Scene][2] = "translate <" + KameraX + "," + KameraY + "," + KameraZ +
">"
PovScene[Scene][3] = "point_at <" + TargetX + "," + TargetY + "," + TargetZ +
">"
PovScene[Scene][4] = "radius 5"
PovScene[Scene][5] = "tightness 50 "
PovScene[Scene][6] = "falloff 20"
PovScene[Scene][7] = "}"

Scene = Scene + 1
PovScene[Scene][0] = "Einfaches helles Licht"
PovScene[Scene][1] = "light_source { <-5000, -25000, -25000> color White"
PovScene[Scene][2] = "fade_distance 100000 fade_power 2"
PovScene[Scene][3] = "}"

Scene = Scene + 1
PovScene[Scene][0] = "TEST"
PovScene[Scene][1] = "light_source {  0*x   color rgb <1,1,1>    spotlight"
PovScene[Scene][2] = "translate <" + KameraX + "," + KameraY + "," + KameraZ +
">"
PovScene[Scene][3] = "point_at <" + TargetX + "," + TargetY + "," + TargetZ +
">"
PovScene[Scene][4] = "radius 180"
PovScene[Scene][5] = "tightness 50 "
PovScene[Scene][6] = "falloff 25"
PovScene[Scene][7] = "fade_distance 2000"
PovScene[Scene][8] = "fade_power 1"
PovScene[Scene][9] = "}"
PovScene[Scene][10] = "light_source {  0*x   color rgb <1,1,1>    spotlight"
PovScene[Scene][11] = "translate <" + KameraX + "," + KameraY + "," + KameraZ +
">"
PovScene[Scene][12] = "point_at <" + TargetX + "," + TargetY + "," + TargetZ +
">"
PovScene[Scene][13] = "radius 180"
PovScene[Scene][14] = "tightness 50 "
PovScene[Scene][15] = "falloff 25"
PovScene[Scene][16] = "fade_distance 2000"
PovScene[Scene][17] = "fade_power 1"
PovScene[Scene][18] = "}"

//////////////////////////////////////////////////////////////////////////////

[dick balaska] Re: pull/74 [3555 days 15 hours and 42 minutes ago]

Wed, 13 Jul 2016 01:15:20 GMT

Am 2016-07-12 17:39, also sprach clipka:
> Am 12.07.2016 um 20:41 schrieb dick balaska:
>>> Commit Summary
>>>
>>>    Refactoring IOStream family of classes.
>>
>> Oh please oh please oh please, let Him be refactoring out that 80 that
>> is hardcoded as a linewidth in a boatload of constructors.
>
> Uh... no, that's way beside my focus, sorry to disappoint you. I'm
> primarily concerned with file input at the lowest level (actual file
> access, implemented by the IOBase(*) family of classes), not file output
> at the highest level (word wrapping, implemented by the TextStreamBuffer
> family of classes).
>
> (*erroneously referred to in the commits and pull request as IOStream)
>

Yeah... I know.
I had that thought, then looked at the diff and saw what you were doing, 
but decided to post that anyway.

Back when I first brought it up I thought fixing it would be a good toe 
dipping exercise, but no.  It's not a config parameter, it's a friggin 
parameter passed in a constructor! (And it's not even a symbol, like 
CONSOLEWIDTH, it's a freakin numeric 80! Argh.)

I still want to fix that, but I have more impovtant things I'm working on...

-- 
dik

[clipka] Re: pull/74 [3555 days 19 hours and 19 minutes ago]

Tue, 12 Jul 2016 21:39:05 GMT

Am 12.07.2016 um 20:41 schrieb dick balaska:
>> Commit Summary
>>
>>    Refactoring IOStream family of classes.
> 
> Oh please oh please oh please, let Him be refactoring out that 80 that
> is hardcoded as a linewidth in a boatload of constructors.

Uh... no, that's way beside my focus, sorry to disappoint you. I'm
primarily concerned with file input at the lowest level (actual file
access, implemented by the IOBase(*) family of classes), not file output
at the highest level (word wrapping, implemented by the TextStreamBuffer
family of classes).

(*erroneously referred to in the commits and pull request as IOStream)

[dick balaska] pull/74 [3555 days 22 hours and 16 minutes ago]

Tue, 12 Jul 2016 18:41:23 GMT

> Commit Summary
 >
 >    Refactoring IOStream family of classes.

Oh please oh please oh please, let Him be refactoring out that 80 that 
is hardcoded as a linewidth in a boatload of constructors.

;)

-- 
dik

[Ken Shumway] Re: Compiling Povray [3580 days 19 hours and 8 minutes ago]

Fri, 17 Jun 2016 21:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 16.06.2016 um 01:06 schrieb Ken Shumway:
> > I'm trying for the first time to compile Povray 3.7. I have the package that is
> > available at github. I've figured how to modify configure.ac to reflect where
> > I've stored the paths to various files requires but now get these error messages
> > from autoconf.
> >
> > error: possibly undefined macro: AM_INIT_AUTOMAKE
> > error: possibley undefined macro: AM_MAINTAINER_MODE
> >
> > I have no idea how to start to fix this. Any suggestions?
>
> The configure.ac is _not_ intended to be modified directly.
>
> If you pull the newest master branch, and look at the install
> instructions in the Unix folder, you should find a note instructing you
> to run
>
>     cd unix
>     ./prebuild.sh
>     cd ..
>
> before anything else. From there on, installation should be more or less
> as you expect, i.e. the next steps should be to execute the
> `./configure` script and then run `make`. (Note though that POV-Ray's
> `./configure` needs a mandatory parameter, something like BUILT_BY or
> COMPILED_BY, I keep forgetting its name; but `./configure` will tell you
> if you invoke it without.)
>
> The reason behind the `prebuild.sh` script is that POV-Ray is maintained
> on GitHub as a platform-neutral project. Among other things this means
> that we don't tolerate any platform-specific stuff whatsoever outside of
> dedicated subdirectories (such as the `unix` and `vfe/unix`
> directories). For platforms where this essentially breaks the build
> process (as is the case on Unix), we provide a special script (namely
> the `prebuild.sh` script in case of the Unix platform) that converts the
> platform-neutral source package (where the platform-specific stuff is
> safely tucked away) into a platform-specific one (where the
> platform-specicif stuff may be all over the place, as required to build).

Thank you for your time.  I'll try to do this as you suggested and ask more
questions if it doesn't work.

[clipka] Re: Compiling Povray [3582 days 3 hours and 48 minutes ago]

Thu, 16 Jun 2016 13:10:06 GMT

Am 16.06.2016 um 01:06 schrieb Ken Shumway:
> I'm trying for the first time to compile Povray 3.7. I have the package that is
> available at github. I've figured how to modify configure.ac to reflect where
> I've stored the paths to various files requires but now get these error messages
> from autoconf.
> 
> error: possibly undefined macro: AM_INIT_AUTOMAKE
> error: possibley undefined macro: AM_MAINTAINER_MODE
> 
> I have no idea how to start to fix this. Any suggestions?

The configure.ac is _not_ intended to be modified directly.

If you pull the newest master branch, and look at the install
instructions in the Unix folder, you should find a note instructing you
to run

    cd unix
    ./prebuild.sh
    cd ..

before anything else. From there on, installation should be more or less
as you expect, i.e. the next steps should be to execute the
`./configure` script and then run `make`. (Note though that POV-Ray's
`./configure` needs a mandatory parameter, something like BUILT_BY or
COMPILED_BY, I keep forgetting its name; but `./configure` will tell you
if you invoke it without.)

The reason behind the `prebuild.sh` script is that POV-Ray is maintained
on GitHub as a platform-neutral project. Among other things this means
that we don't tolerate any platform-specific stuff whatsoever outside of
dedicated subdirectories (such as the `unix` and `vfe/unix`
directories). For platforms where this essentially breaks the build
process (as is the case on Unix), we provide a special script (namely
the `prebuild.sh` script in case of the Unix platform) that converts the
platform-neutral source package (where the platform-specific stuff is
safely tucked away) into a platform-specific one (where the
platform-specicif stuff may be all over the place, as required to build).

[Le Forgeron] Re: Compiling Povray addendum [3582 days 10 hours and 40 minutes ago]

Thu, 16 Jun 2016 06:17:47 GMT

Le 16/06/2016 Ã  01:09, Ken Shumway a Ã©crit :
> I neglected to mention, I'm doing this on Ubuntu 14.04
>
>
Which branch did you get from github ?
(hint: stable or master ? or did you get some snapshot without using git ?)

(not that I still have a 14.04 at hand)

You talked about modifications of configure.ac, can you elaborate on 
that point ?

[Ken Shumway] Compiling Povray addendum [3582 days 17 hours and 48 minutes ago]

Wed, 15 Jun 2016 23:10:01 GMT

I neglected to mention, I'm doing this on Ubuntu 14.04

[Ken Shumway] Compiling Povray [3582 days 17 hours and 48 minutes ago]

Wed, 15 Jun 2016 23:10:00 GMT

I'm trying for the first time to compile Povray 3.7. I have the package that is
available at github. I've figured how to modify configure.ac to reflect where
I've stored the paths to various files requires but now get these error messages
from autoconf.

error: possibly undefined macro: AM_INIT_AUTOMAKE
error: possibley undefined macro: AM_MAINTAINER_MODE

I have no idea how to start to fix this. Any suggestions?

[clipka] Re: using console version in windows [3653 days and 19 minutes ago]

Wed, 6 Apr 2016 16:38:53 GMT

Am 06.04.2016 um 16:10 schrieb whenuwishupon:
> I solved the problem for master source code. I forgot to select Windows Targets
> -> console as start-up Project. 92 warnings, but povconsole64.exe is there.
> Now I will test it.
> 
> what's the difference between stable and master source code?


The stable branch holds the latest official release, currently 3.7.0.

Any behaviour -- whether intentional or otherwise -- of a "stable"
release becomes "canonical" in the sense that you can reasonably expect
future versions to behave in the same manner, provided you make proper
use of the "#version" statement. (Behaviour resulting from bugs that a
user cannot possibly mistake for being intentional is routinely exempt
from this protection, and features explicitly reported as "experimental"
also have some risk of being intentionally changed as well.)

Also, "stable" versions have undergone a phase of pure bugfixing, so
presumably they contain comparatively few bugs.


The master branch, on the other hand, is where development happens,
currently in preparation for what will become 3.7.1.

On the upside, this means that the version will contain the latest and
greatest new features.

On the downside, any behaviour of a development version that differs
from the previous stable release may be subject to change without notice.

Also, development versions are more prone to bugs.


At present however, the value of the "stable" branch happens to be
greatly diminished by the following factors:

- C++11: The new standard has become widely adopted /after/ the latest
stable version; as it turns out, POV-Ray contained various
incompatibilities with the new standard, so contemporary build
environments like Visual Studio 2015 or modern versions of GCC gag on
the latest stable version. Even in the master branch the C++11-related
problems have only recently been ironed out completely.

- Boost and Automake: Both boost 1.50 and a comparatively recent
Automake incarnation introduced some breaking changes that interfered
with our Unix build process, and which we found time to work around only
after the latest stable release (mainly because the primary developers
are notorious Windows jockeys).

- Sub-optimal software lifecycle management: Ideally, when bugs or
issues are discovered that were already present in the latest stable
version, they should be fixed in the stable branch and then ported to
the development branch. However, in the past, both feature and bugfixing
development has been made on the master branch, and to this day nobody
has made the endeavour to isolate and port those fixes to the stable branch.

[whenuwishupon] Re: using console version in windows [3653 days 2 hours and 43 minutes ago]

Wed, 6 Apr 2016 14:15:00 GMT

I solved the problem for master source code. I forgot to select Windows Targets
-> console as start-up Project. 92 warnings, but povconsole64.exe is there.
Now I will test it.

what's the difference between stable and master source code?

[whenuwishupon] Re: using console version in windows [3653 days 3 hours and 58 minutes ago]

Wed, 6 Apr 2016 13:00:00 GMT

Hey, thank you for your answers.

> >>>> You surely mean Visual Studio, right?

Yes I meant Visual Studio. Not Visual Basic. Sry

> >>> I think he just wants to create a program that writes pov files
> >>> based on parameters and then renders via command line. No need to
> >>> build own version of pov or use c++ for that.

No. I want a standalone console build without GUI, if possible.

> I suppose, yes.  It still opens the povwin window though, which is
> annoying if you want to do background renders. (focus stealing monster)

That's what I want to avoid. The extern program would have to open the hole GUI
for every frame. Just like you said. My wish is to have background rendering.


Now I have Visual Studio 2015 Community. I downloaded the MASTER open source 3.7
and followed the instruction. I activated _CONSOLE in
\povray-master\povray-master\windows\povconfig\syspovconfig.h(it's in
\povray-3.7-stable\povray-3.7-stable\vfe\win in the stable version)


I also activated "console" and deactivated "GUI" in the build-configuration of
Visual Studio. I built x64 release with local debugger. No Errors, few warnings.
But Visual Studio couldn't start and find povengine.exe.

So I did the same process with "GUI" activated. I received 1 error "#error:  You
are building the GUI platform with _CONSOLE defined (check
vfe\win\syspovconfig.h)." and Visual Studio also couldn't start and find
povengine.exe .

What did I do wrong?

The stable Version works very badly for me. Same result. But with 140 errors.

[dick balaska] Re: using console version in windows [3653 days 20 hours and 35 minutes ago]

Tue, 5 Apr 2016 20:22:22 GMT

Am 2016-04-05 13:20, also sprach Le_Forgeron:
> Le 05/04/2016 17:47, dick balaska a Ã©crit :
>> Am 2016-04-05 09:38, also sprach Christian Froeschlin:
>>> On 03.04.2016 15:01, clipka wrote:
>>>
>>>> You surely mean Visual Studio, right?
>>>
>>> I think he just wants to create a program that writes pov files
>>> based on parameters and then renders via command line. No need to
>>> build own version of pov or use c++ for that.
>>
>> You need to build your own version of povconsole(64).exe. There are no published
executables for that.
>>
>>
> cannot he used the official binary with the right option ?
>
> such as /NR /EXIT /RENDER and may be /THREADS
>
>  
http://wiki.povray.org/content/Documentation:Windows_Section_3#Special_Command-Line_Options

I suppose, yes.  It still opens the povwin window though, which is 
annoying if you want to do background renders. (focus stealing monster)


-- 
dik

[Le Forgeron] Re: using console version in windows [3653 days 23 hours and 38 minutes ago]

Tue, 5 Apr 2016 17:20:05 GMT

Le 05/04/2016 17:47, dick balaska a Ã©crit :
> Am 2016-04-05 09:38, also sprach Christian Froeschlin:
>> On 03.04.2016 15:01, clipka wrote:
>>
>>> You surely mean Visual Studio, right?
>>
>> I think he just wants to create a program that writes pov files
>> based on parameters and then renders via command line. No need to
>> build own version of pov or use c++ for that.
> 
> You need to build your own version of povconsole(64).exe. There are no published
executables for that.
> 
> 
cannot he used the official binary with the right option ?

such as /NR /EXIT /RENDER and may be /THREADS

 http://wiki.povray.org/content/Documentation:Windows_Section_3#Special_Command-Line_Options

[dick balaska] Re: using console version in windows [3654 days 1 hour and 10 minutes ago]

Tue, 5 Apr 2016 15:47:35 GMT

Am 2016-04-05 09:38, also sprach Christian Froeschlin:
> On 03.04.2016 15:01, clipka wrote:
>
>> You surely mean Visual Studio, right?
>
> I think he just wants to create a program that writes pov files
> based on parameters and then renders via command line. No need to
> build own version of pov or use c++ for that.

You need to build your own version of povconsole(64).exe. There are no 
published executables for that.


-- 
dik

[Christian Froeschlin] Re: using console version in windows [3654 days 3 hours and 19 minutes ago]

Tue, 5 Apr 2016 13:38:41 GMT

On 03.04.2016 15:01, clipka wrote:

> You surely mean Visual Studio, right?

I think he just wants to create a program that writes pov files
based on parameters and then renders via command line. No need to
build own version of pov or use c++ for that.

[clipka] Re: using console version in windows [3656 days 3 hours and 56 minutes ago]

Sun, 3 Apr 2016 13:01:14 GMT

Am 02.04.2016 um 22:14 schrieb whenuwishupon:
> Thank you for the positive responses and your time. Your experience gives me
> confidence to not wasting time on this problem. Next week my university will
> provide me with a Visual Basic Standard Licence. Therefore I can't test it now.
> Report follows.

You surely mean Visual Studio, right?

POV-Ray is written in C++, so Visual Basic will get you nowhere; you'll
need Visual C++. Microsoft Visual Studio includes both.

As far as licenses are concerned, as a student you most likely qualify
for the free Community edition of Visual Studio 2015, which is known to
work "out of the box" with the current master branch of POV-Ray (unlike
the Express editions of older Visual Studio versions).

[whenuwishupon] Re: using console version in windows [3656 days 20 hours and 38 minutes ago]

Sat, 2 Apr 2016 20:20:00 GMT

Thank you for the positive responses and your time. Your experience gives me
confidence to not wasting time on this problem. Next week my university will
provide me with a Visual Basic Standard Licence. Therefore I can't test it now.
Report follows.

[dick balaska] Re: using console version in windows [3656 days 23 hours and 45 minutes ago]

Sat, 2 Apr 2016 17:12:39 GMT

Am 2016-04-02 10:40, also sprach clipka:
> Am 02.04.2016 um 15:04 schrieb whenuwishupon:

What clipka said.

I have been using the console version pretty heavy for about 6 months.
I add
-L/Users/dick/Documents/POV-Ray/v3.7/include -wt8
to the command line. My quad core i7 has 8 threads (-wt8) and -L 
obviously points to the povray include files.

I, too, run heavily automated povconsole64.exe .  The only downer I've 
seen is once in a blue moon, povconsole will exit immediately without 
generating any output whatsoever. (out of 26,532 renders this has 
happened maybe 30 times). Other than that, it runs great.

I don't do shellout commands, so I can't comment on that. I can't really 
see the need for them.
I do animation, and I prefer -SF100 -EF100 on the command line and keep 
the .ini file constant. One frame per povconsole call.
-- 
dik

[clipka] Re: using console version in windows [3657 days 2 hours and 17 minutes ago]

Sat, 2 Apr 2016 14:40:18 GMT

Am 02.04.2016 um 15:04 schrieb whenuwishupon:

> So for implementing povray in my main programm, I need the console version.  In
> the source I found the windows/readme.txt. It describes how to build up a
> primitive console version. "..., please modify the configuration as needed, edit
> vfe\win\syspovconfig.h to enable the definition of _CONSOLE as noted
> therein, and build." Ok, easy step.
> But it says also that this console version is only a "simple example" and "If
> you wish to make a more comprehensive console that runs on windows, please use
> the unix version as a guide,..."
> 
> My questions: Is the primitive console version of POVRay for my purpose/idea
> sufficing? --> Loading .pov , .ini , start .ini Animation , resolution input,
> adjust ouput direction.

I'm not sure what exactly the limitations of the console version are,
but it should be perfectly fine for your purposes.

You might need to specify the number of render threads manually, or
might not get to limit file output to whitelisted directories, or stuff
like that, and of course you won't get a preview display. But the
processing of .ini and .pov files is fully functional (except maybe
shellout commands).

> Is there a list of commands to use for the console? in the documentation?

There isn't any magic to it. Just pass the name of the .ini file as a
command line parameter.

[whenuwishupon] using console version in windows [3657 days 3 hours and 48 minutes ago]

Sat, 2 Apr 2016 13:10:00 GMT

Hey folks :)

i'm an aerospace engineer student working on my thesis. One objective is to
write a program for light curves simulation. for this purpose i'm gratefully
using povray because of its realism. The problem is that i want to adjust
parameters in POVRay (like reflection) without always rewriting the povray
skript and without running it seperately.

My idea is to let my main program write an .pov and .ini file after confirming
the parameters. The next step for the main program is to open the console
version of POVRay and initialise rendering with these files.(Starting .ini for
Animation)
The ouput pictures do not need to be shown. Now my main program takes the lead
again and makes use of the pictures.

So for implementing povray in my main programm, I need the console version.  In
the source I found the windows/readme.txt. It describes how to build up a
primitive console version. "..., please modify the configuration as needed, edit
vfe\win\syspovconfig.h to enable the definition of _CONSOLE as noted
therein, and build." Ok, easy step.
But it says also that this console version is only a "simple example" and "If
you wish to make a more comprehensive console that runs on windows, please use
the unix version as a guide,..."

My questions: Is the primitive console version of POVRay for my purpose/idea
sufficing? --> Loading .pov , .ini , start .ini Animation , resolution input,
adjust ouput direction.

Or need I built up the unix version to a win executive with MinGW or Cygwin?
(is it complicated?)

Is there a list of commands to use for the console? in the documentation?

Whats the easiest way to achieve my purpose?


Thank you very much in advance. Sry for my bad english. I hope you understand
most of my text:)

Have a nice weekend!

Daniel

[clipka] Re: Inquiring about features [3682 days 7 hours and 44 minutes ago]

Tue, 8 Mar 2016 09:13:39 GMT

Am 08.03.2016 um 06:48 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> An object that is part of a CSG but doesn't take part in CSG?
>> That makes absolutely NO sense to me at all. Care to try a different
>> approach at explaining it to me?
> 
> It doesn't make any less sense than having an object in between a light source
> and another object, yet not cast a shadow.  (no_shadow)
> or not be reflected (no_reflection)
> or not even "be there" at all (no_image)

Note that I wrote "[it] makes [...] no sense TO ME [...]" (emphasis
changed). It still doesn't, because...

> I guess the idea is that if you're stuck defining an object in a scene, and for
> "reasons", it needs to be defined within some sort of CSG operation, then it
> might be useful to "opt it out" of the CSG.

... I have no idea what such "reasons" could be. At present, the only
reason I can think of for putting something into a CSG is to have it
participate in that particular CSG.

But given that you're suggesting it, I presume you do have a use case?

>> I see nothing that stands in the way of implementing such stuff as
>> macros, except maybe for the fact that trace() does not currently return
>> UV coordinates.
> 
> Doesn't trace() return the coordinates of the object's surface, regardless of
> color/texture?
> If I have an object patterned by onion or wood, trace() would only return the
> coordinates of the outermost surface.
> I'm suggesting a trace() that would go THROUGH any color other than the one
> specified.  Just a light ray goes through a pigment with a transmit value of 1
> even though the object is still there.

That doesn't stand in the way of developing a macro: Once you have found
the first intersection point, use eval_pigment() to determine the colour
(including transparency). If the pigment is transparent, trace() again
from the intersection point you just found. Rinse and repeat.

One reason (and actually a quite severe one) why such a thing is not
supported out of the box is that POV-Ray objects have textures, not
pigments -- and textures can get arbitrarily complex, with compositing
rules that go way beyond the domain of pigments. So there are cases when
there is no such thing as "/the/ pigment" of an object.

[scott] Re: Inquiring about features [3682 days 9 hours and 12 minutes ago]

Tue, 8 Mar 2016 07:46:10 GMT

>> Can an object be defined in a scene as part of let's say for demonstration
>> purposes, a difference, be rendered, but NOT take part in CSG?
>> I'm not sure how useful it would be, although I can imagine having an object
>> somewhere that fades out in an animation and doesn't leave a hole.
>> maybe a tag like no_csg
>
> An object that is part of a CSG but doesn't take part in CSG?
> That makes absolutely NO sense to me at all. Care to try a different
> approach at explaining it to me?

I think he means that this:

difference
{
  objectA
  objectB no_csg
  objectC
}

would then render equivalently to this:

objectB
difference
{
  objectA
  objectC
}

But it would get confusing if you have multiple nested levels of csg, 
what should happen then? Maybe an integer parameter after the "no_csg" 
keyword to say how many levels "up" the object should go (0=scene root)

[Bald Eagle] Re: Inquiring about features [3682 days 11 hours and 8 minutes ago]

Tue, 8 Mar 2016 05:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> An object that is part of a CSG but doesn't take part in CSG?
> That makes absolutely NO sense to me at all. Care to try a different
> approach at explaining it to me?

It doesn't make any less sense than having an object in between a light source
and another object, yet not cast a shadow.  (no_shadow)
or not be reflected (no_reflection)
or not even "be there" at all (no_image)

I guess the idea is that if you're stuck defining an object in a scene, and for
"reasons", it needs to be defined within some sort of CSG operation, then it
might be useful to "opt it out" of the CSG.
Not sure if it's possible with the way the rendering engine is coded, but it
seemed like something I'd post here for consideration.

> > A split, or multi-image feature.
> > Let's say I want to render a LARGE image, and want it split up in a 3x3 grid
> > into 9 images of equal size.
> > Related to this, I was thinking that the partial render feature would be nice if
> > there were a way to select a region, and have it get saved to a secondary file
> > aside from the main render.
>
> Have /what/ get saved -- the partial render parameters? The image? And
> what do you mean by "aside from the main render?"

Yes.
Have the selected region be saved as a small image, independent of the larger
main render window.  If I select an 80x80 pixel region to render, and my
resolution is set at 640x480, then POV-Ray normally saves the 640x480 as
filename.png.  I just thought it might be useful to ALSO save the selected 80x80
region as a seperate file - with a suffixed filename like filename(1).png or
filename_selection.png.

> Are you thinking along the lines of a kind of "auto-crop" feature,
> effectively trimming down your output image to contain only the portion
> actually rendered?

Yes, but the auto-cropped, trimmed-down output image gets saved in addition to
the usual output.

> I see nothing that stands in the way of implementing such stuff as
> macros, except maybe for the fact that trace() does not currently return
> UV coordinates.

Doesn't trace() return the coordinates of the object's surface, regardless of
color/texture?
If I have an object patterned by onion or wood, trace() would only return the
coordinates of the outermost surface.
I'm suggesting a trace() that would go THROUGH any color other than the one
specified.  Just a light ray goes through a pigment with a transmit value of 1
even though the object is still there.

[clipka] Re: Inquiring about features [3683 days 6 hours and 41 minutes ago]

Mon, 7 Mar 2016 10:16:58 GMT

Am 07.03.2016 um 00:52 schrieb Bald Eagle:
> 
> Curious, and planting the seeds for some ideas.
> 
> Can an object be defined in a scene as part of let's say for demonstration
> purposes, a difference, be rendered, but NOT take part in CSG?
> I'm not sure how useful it would be, although I can imagine having an object
> somewhere that fades out in an animation and doesn't leave a hole.
> maybe a tag like no_csg

An object that is part of a CSG but doesn't take part in CSG?
That makes absolutely NO sense to me at all. Care to try a different
approach at explaining it to me?

When you're talking about fading stuff out, I think of the "blink"
feature I've implemented in UberPOV; maybe that's what you're thinking
about? (UberPOV's features are documented in its "changes.txt" file; in
a nutshell, it allows to make an object semi-transparent /as a whole/,
without exposing its interior like a semi-transparent material would.)

> A split, or multi-image feature.
> Let's say I want to render a LARGE image, and want it split up in a 3x3 grid
> into 9 images of equal size.
> Related to this, I was thinking that the partial render feature would be nice if
> there were a way to select a region, and have it get saved to a secondary file
> aside from the main render.

Have /what/ get saved -- the partial render parameters? The image? And
what do you mean by "aside from the main render?"

Are you thinking along the lines of a kind of "auto-crop" feature,
effectively trimming down your output image to contain only the portion
actually rendered?

> a "colorblind" Trace() that can ignore all colors except the specified one.
> or ignore a specified one, and only returns regions of objects NOT that color.
> I guess it would be sorta like a combo between eval_pigment and trace().
> I can envision using a transparent background png as a pigment, and then tracing
> around it - with this new trace().   One could find outlines, make rough mesh
> models, etc.   Potentially useful in CSG once objects were created that
> originated from transparent background images.

I see nothing that stands in the way of implementing such stuff as
macros, except maybe for the fact that trace() does not currently return
UV coordinates.

[Bald Eagle] Inquiring about features [3683 days 17 hours and 3 minutes ago]

Sun, 6 Mar 2016 23:55:00 GMT

Curious, and planting the seeds for some ideas.

Can an object be defined in a scene as part of let's say for demonstration
purposes, a difference, be rendered, but NOT take part in CSG?
I'm not sure how useful it would be, although I can imagine having an object
somewhere that fades out in an animation and doesn't leave a hole.
maybe a tag like no_csg

A split, or multi-image feature.
Let's say I want to render a LARGE image, and want it split up in a 3x3 grid
into 9 images of equal size.
Related to this, I was thinking that the partial render feature would be nice if
there were a way to select a region, and have it get saved to a secondary file
aside from the main render.

a "colorblind" Trace() that can ignore all colors except the specified one.
or ignore a specified one, and only returns regions of objects NOT that color.
I guess it would be sorta like a combo between eval_pigment and trace().
I can envision using a transparent background png as a pigment, and then tracing
around it - with this new trace().   One could find outlines, make rough mesh
models, etc.   Potentially useful in CSG once objects were created that
originated from transparent background images.

[dick balaska] Re: Broken Arrow [3709 days 21 hours and 45 minutes ago]

Tue, 9 Feb 2016 19:12:29 GMT

On 1/28/2016 9:49 AM, clipka wrote:

>
>> About the ordering of libraries, when libA would need some part of libB,
>> libA must appears before libB. But if libB needs also some code of libA,
>> you got a problem of circular dependencies which can make it difficult
>> to solve: the linker will extract only the needed symbol from libA due
>> to the previous code (main or other *.o object) and get a list of needed
>> symbols. then it close forever libA and search libB to extract the still
>> needed symbols and might get more needed symbols too. rinse & repeat for
>> the next library until the end of the list.
>
> Are you sure that's what's happening? Because last time I checked, there
> is no problem linking two libraries into one executable even if they
> recursively call each other. And I don't think it can't get any more
> interlocked than that.

Huh. I would have agreed with clipka; I thought this problem was solved 
long ago.  But I just ran into this situation with my animation 
controller.  I was refactoring my networking and the lower layer must be 
on the link line after the higher layer that calls it. It took me awhile 
to think of reordering the link line...
"What do you mean void AgentRead(SOCKET) not found?? It's been there for 
20 years!"
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

[clipka] Re: Warning! Error in source Povray-3.7 [3710 days 19 hours and 54 minutes ago]

Mon, 8 Feb 2016 21:03:15 GMT

Am 08.02.2016 um 18:15 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 07.02.2016 um 23:52 schrieb LanuHum:
>>> [rant rant rant rant rant...]
>>
>> I'm sorry, but the above is really everything I understand from your
>> postings. That's how bad your English is, and that is why I tended to
>> not respond to your posts.
>>
> 
> 
> I well understand that here nobody understands me. :):):)
> I try to be silent.
> I don't know why online translators so badly work.
> I joked.
> Today New year in the east.
> I congratulate all on a year of a fiery monkey!
> It was understood?
> :):):)

Is that some traditional prank day in the East, like April Fools' day in
western culture?
I guess you got me there.

> Sorry, that I can't be the witness.

And once again I don't know what you mean to say by this. :)
*Sigh!*

[LanuHum] Re: Warning! Error in source Povray-3.7 [3710 days 23 hours and 38 minutes ago]

Mon, 8 Feb 2016 17:20:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 07.02.2016 um 23:52 schrieb LanuHum:
> > [rant rant rant rant rant...]
>
> I'm sorry, but the above is really everything I understand from your
> postings. That's how bad your English is, and that is why I tended to
> not respond to your posts.
>

I well understand that here nobody understands me. :):):)
I try to be silent.
I don't know why online translators so badly work.
I joked.
Today New year in the east.
I congratulate all on a year of a fiery monkey!
It was understood?
:):):)

Sorry, that I can't be the witness.

[clipka] Re: Warning! Error in source Povray-3.7 [3711 days 16 hours and 41 minutes ago]

Mon, 8 Feb 2016 00:16:42 GMT

Am 07.02.2016 um 23:52 schrieb LanuHum:
> [rant rant rant rant rant...]

I'm sorry, but the above is really everything I understand from your
postings. That's how bad your English is, and that is why I tended to
not respond to your posts.

Also, why the sudden ranting? A night of too much vodka?


Somewhere in your post I sense that you are discontent with how we
develop the current version of POV-Ray. You seem to try to express that
since we didn't write the original version of POV-Ray, we wouldn't have
the right to decide the future of POV-Ray.

Well, the future of POV-Ray has always been decided by whoever was
writing the code, or whoever was piecing together an official version
from code written by other contributors. Originally that was David K.
Buck (when POV-Ray was still DKB-Trace), later it was a dev team around
Chris Cason, and at present I'm the one with the most time and energy
available to invest into POV-Ray, so I guess that /does/ give me the
right (and responsibility) to influence where POV-Ray is heading /at
present/. Should someone else take over the bulk of development work
some time in the future, then it'll be up to them to make such decisions
/from then on/.

It would be a different thing if anyone paid me for the time and energy
I invest. But I don't see that happening.


From your post I get the impression that you are trying to say "you will
be sorry for this", but I am unable to understand any details, so I have
not much of a clue what we did wrong to feel sorry for, or how you
intend to make us feel sorry for it.

I somehow get the impression that you intend to cease work on your
unofficial Blender-to-POV-Ray exporter. Please let me tell you that
although I virtually never commented on it, and although I do not use
Blender myself, I do consider it a most valuable contribution.

However, if your posting is intended as a threat or the announcement of
some punishment, don't hesitate to get lost. I do not consider threat or
punishment a good basis for any type of cooperaton, and would rather
lose valuable contributions than to endure such a destructive form of
person-to-person interaction.


I may be totally misunderstanding you -- I have no way of knowing,
because your English is, unfortunately, exceptionally bad.


As for other input to the POV-Ray project, I must say that in many cases
your style of writing comes across to me as rude and ranting, while I
understand little of what you actually want to say. Your poor English
is, unfortunately, a big barrier there as well, and from my side there
is little I can do to overcome it. Please be aware that I might
occasionally take home a few ideas from your posts even if I don't
answer. Also, please do not expect me to answer on a regular basis,
because trying to understand your posts tends to tire me out real quick,
so I try to avoid getting engaged in any discussion with you.

Please do not take this as a sign of disrespect -- this is simply a
matter of protecting myself from too much frustration. I really have a
lot of difficulty trying to understand what you are trying to say, and
what emotions you are trying to express. And if there's one thing that
/really/ frustrates me, it's failing to understand something.

[LanuHum] Re: Warning! Error in source Povray-3.7 [3711 days 18 hours and 3 minutes ago]

Sun, 7 Feb 2016 22:55:01 GMT

You are mistaken if considers himself the cleverest. People have to be on
friendly terms, you don't want to be on friendly terms
I considered that everyone can perform the work, but I have to work for you.
Thanks!
You didn't write Povray-001, and, not to you to solve what will be Povray 399
You want that was on yours, and I want that was in my opinion.
That do you want? To become idols from Easter Island? I already prepare a stone
from which I will turn your figures!
Go to people to a navtrech if the Sansara wheel to you is thin. If isn't
present, then write raytracing 2 frames a year
You have strong arguments for an animtion, and you try to compete to lux-render
It isn't necessary for you!

[LanuHum] Re: Warning! Error in source Povray-3.7 [3711 days 18 hours and 38 minutes ago]

Sun, 7 Feb 2016 22:20:01 GMT

Clipka, Jerome!
In vain you ignored me.
Didn't want on good, will be to you on bad
I study ocaml, I will write raytracing.
Was you 7 here, will be 3.5
I'm Russian!
It is better to be on friendly terms with me, than to be at war.
To a meeting in the battlefield that there is raytracing.
I could attach the Blender to Povray, I will be able to untie you from Povray.
We will conclude a bet, or you so will believe?
It wasn't pleasant to me that you ignore me. You it is cleverer than me?
Go you to hell
Thanks! Hellow! Good By!
I will take away algorithms from Istman
I will transfer them to highly productive code.
You not the cleverest if you don't want to conduct dialogue with me.
Once again excuse. You expressed disrespect for me, I to you will answer the
same.
I will drown your Poser To which you worship
Farewell!
As Khrushchev in the UN once told, I to you will show to a kuzkin mother.
:) :) :)

[Le Forgeron] Re: Broken Arrow [3722 days and 16 minutes ago]

Thu, 28 Jan 2016 16:41:39 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 28/01/2016 15:49, clipka a Ã©crit :
> Are you sure that's what's happening? Because last time I checked,
> there is no problem linking two libraries into one executable even
> if they recursively call each other. And I don't think it can't get
> any more interlocked than that.

If you "link" with shared libraries, usually no problem. (but you get
other kind of problems)

But try doing that with static libraries, and the linker can be a PITA.
Well, some linkers... not all of them.

Recursive calls might be ok ( A::a calls B::b which calls again A::a,
the linker might have kept the A::a name, so all is fine. but in some
situation like A::a calls B::b which calls A::z, very first reference
of it ever, which then calls B::c, also first time,...and so on, it
can badly fails). Notice that such intricacy is usually a sign of a
design problem (easy solution: merge both libraries into a single one) )
.

Some linkers try to be smart, to reduce the size of the final binary,
so getting only the parts they really need from the static libraries.

Some other linkers are less smart: take everything, resolves name and
complains when provided more than once, leaving unresolved names up to
any system dynamic library (then execution will fails to resolve them,
but that's not the linker's problem anymore).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlaqRMIACgkQhKAm8mTpkW3uSgP/TpH1axrUc3UXfK+l69bQ+lma
LUgGQ/pfWQkWYCItTcZYa997j0zzN/BEjEYMGSAhnZRM8Kre4sZ187VZDK+ZGPSK
OWVm0UeOc5pzDFH6LoWZp3yaf80mkpKg79TL4RtrE4Kr5Z57kKhi6rpKojBeDcNr
Nidr9RW2jDOK58ntjew=
=iBFV
-----END PGP SIGNATURE-----

[clipka] Re: Broken Arrow [3722 days 2 hours and 8 minutes ago]

Thu, 28 Jan 2016 14:49:46 GMT

Am 28.01.2016 um 09:52 schrieb Le_Forgeron:

> Such error at link stage are usually due to:
>  * a failure to compile some code
>  * an ordering problem with multiple libraries on the linker command
> 
> Did you start with a clean environment ? Previously compiled files might
> not have been recompiled and might miss a deep change of mapping.

The error was first brought to my attention by Semaphore, one of the
automated build services I've set up for our GitHub repo. They do start
with as clean an environment as you can possibly imagine.

> About the ordering of libraries, when libA would need some part of libB,
> libA must appears before libB. But if libB needs also some code of libA,
> you got a problem of circular dependencies which can make it difficult
> to solve: the linker will extract only the needed symbol from libA due
> to the previous code (main or other *.o object) and get a list of needed
> symbols. then it close forever libA and search libB to extract the still
> needed symbols and might get more needed symbols too. rinse & repeat for
> the next library until the end of the list.

Are you sure that's what's happening? Because last time I checked, there
is no problem linking two libraries into one executable even if they
recursively call each other. And I don't think it can't get any more
interlocked than that.


No, it was an entirely different matter: The Unix syspovconfig.h failed
to explicitly pull in <stdint.h>, and typically ended up with the
(false) conclusion that uint32_t wasn't available, resulting in
POV_UINT32, and by extension POVMS_Type, to be defined as unsigned long
(chosen as the default because that's the smallest type guaranteed by
the C++ standard to hold a 32-bit unsigned integer). In other cases
however, <stdint.h> would happen to be included before syspovconfig.h,
which then ended up with the (proper) conclusion that uint32_t was well
available, resulting in POV_UINT32, and by extension POVMS_Type, to be
defined as that type.

Obviously this brought into existence two different sets of declarations
for virtually the entire POVMS module, but only one set of definitions.

The problem hadn't surfaced earlier because POVMS_Type explicitly
defaulted to unsigned int until now.

[Le Forgeron] Re: Broken Arrow [3722 days 8 hours and 5 minutes ago]

Thu, 28 Jan 2016 08:52:33 GMT

Le 28/01/2016 06:38, clipka a Ã©crit :
> Okay, folks -- I'm officially puzzled here.
>
> I've broken the Unix build process, but for the sake of my life can't
> figure out /how/. Here's the change by which I broke it:
>
> https://github.com/POV-Ray/povray/tree/fdcb3676507e8907922dfc6dace95d449ae7860f
>
> And here are the devastating results:
>
> https://semaphoreci.com/pov-ray/povray/branches/master/builds/5
>
> Somehow it seems that the definitions in povmscpp.cpp (and other .cpp
> files in the ~/source/povms subdirectory) are no longer properly linked
> into ~/source/libpovray.a for /some/ reason.
>
> Someone help me out here. Plz.
>

Such error at link stage are usually due to:
  * a failure to compile some code
  * an ordering problem with multiple libraries on the linker command

Did you start with a clean environment ? Previously compiled files might 
not have been recompiled and might miss a deep change of mapping.

If you moved some files, was the Makefile redone ?

About the ordering of libraries, when libA would need some part of libB, 
libA must appears before libB. But if libB needs also some code of libA, 
you got a problem of circular dependencies which can make it difficult 
to solve: the linker will extract only the needed symbol from libA due 
to the previous code (main or other *.o object) and get a list of needed 
symbols. then it close forever libA and search libB to extract the still 
needed symbols and might get more needed symbols too. rinse & repeat for 
the next library until the end of the list.

[clipka] Re: Broken Arrow [3722 days 9 hours and 1 minute ago]

Thu, 28 Jan 2016 07:56:24 GMT

Am 28.01.2016 um 06:38 schrieb clipka:
> Okay, folks -- I'm officially puzzled here.
> 
> I've broken the Unix build process, but for the sake of my life can't
> figure out /how/. Here's the change by which I broke it:
> 
> https://github.com/POV-Ray/povray/tree/fdcb3676507e8907922dfc6dace95d449ae7860f

Ah, never mind -- got it sorted out. In a sense that commit didn't break
anything, it just revealed a pre-existing error in the code.

[clipka] Broken Arrow [3722 days 11 hours and 19 minutes ago]

Thu, 28 Jan 2016 05:38:38 GMT

Okay, folks -- I'm officially puzzled here.

I've broken the Unix build process, but for the sake of my life can't
figure out /how/. Here's the change by which I broke it:

https://github.com/POV-Ray/povray/tree/fdcb3676507e8907922dfc6dace95d449ae7860f

And here are the devastating results:

https://semaphoreci.com/pov-ray/povray/branches/master/builds/5

Somehow it seems that the definitions in povmscpp.cpp (and other .cpp
files in the ~/source/povms subdirectory) are no longer properly linked
into ~/source/libpovray.a for /some/ reason.

Someone help me out here. Plz.

[Benjamin Chambers] Re: How about bi-directional Path Tracing in Ope... [3743 days 12 hours ago]

Thu, 7 Jan 2016 04:57:36 GMT

The source to POV is freely available. Please, do like the makers of 
isoPOV or MegaPOV have done, and release a custom version showing us 
what you can do!

[Theogott] How about bi-directional Path Tracing in OpenCL? [3747 days 4 hours and 43 minutes ago]

Sun, 3 Jan 2016 12:15:01 GMT

Details for implementation see in this video:
http://fr.slideshare.net/takahiroharada/introduction-to-bidirectional-path-tracing-bdpt-implementation-using-opencl-ced
ec-2015

Here is a more general video but its 1 year old.
http://fr.slideshare.net/takahiroharada/introduction-to-monte-carlo-ray-tracing-opencl-implementation-cedec-2014?relate
d=1

Why is OpenCL so important for the future of Raytracing?

Some years ago we had two versions of POV-Ray, one version with SSE, and one
"Normal version". How much faster was this SSE-Version really?
1,2,6 times faster?

Thats nothing compared to what you can reach using OpenCL and a actual GPU.
We are starting with 10x and going up to 30x faster.

Here is another example realtime Particel-Physics for streamlining objects:
https://www.youtube.com/watch?v=XISqvBVyASo

GPU-Technology:
https://www.youtube.com/watch?v=7E7qCs1q6JQ

See the future ...
https://www.youtube.com/watch?v=EY8rAvf45j4

[clipka] Re: Forked for VS2015 [3769 days 17 hours and 21 minutes ago]

Fri, 11 Dec 2015 23:36:24 GMT

Am 11.12.2015 um 23:50 schrieb Benjamin Chambers:
> Hey, look what happens when I get distracted for a few months :-D

Maybe you should get distracted more often ;)

> Checking out the /master branch now...

Let me know how the changes work out for you.

[Benjamin Chambers] Re: Forked for VS2015 [3769 days 18 hours and 7 minutes ago]

Fri, 11 Dec 2015 22:50:58 GMT

Hey, look what happens when I get distracted for a few months :-D

Checking out the /master branch now...

[Dick Balaska] Re: render differences in github/head and 3.7 [3770 days 1 hour and 16 minutes ago]

Fri, 11 Dec 2015 15:41:40 GMT

In article <566ad86b$1@news.povray.org>, ano### [at] anonymousorg says...
> > It's the Jade pigment in textures.inc.  I also noticed it with 
> > Apocolypse.
> > Oddly, I also use Blood_Marble and Blue_Sky3 and those seem fine.
> 
> Not here: Blood_Marble is just as broken. Haven't tested Blue_Sky3 yet,
> but I suspect it won't be any good either.

Yes, I was mistaken. They are both broken as well.

[clipka] Re: render differences in github/head and 3.7 [3770 days 2 hours and 51 minutes ago]

Fri, 11 Dec 2015 14:06:35 GMT

Am 10.12.2015 um 22:22 schrieb Dick Balaska:

> I was a little hasty with the 'send' button before because I wanted to 
> mention I didn't think you'd want such variance between 3.7.0 and 3.7.1
> 
> It's the Jade pigment in textures.inc.  I also noticed it with 
> Apocolypse.
> Oddly, I also use Blood_Marble and Blue_Sky3 and those seem fine.

Not here: Blood_Marble is just as broken. Haven't tested Blue_Sky3 yet,
but I suspect it won't be any good either.

[Dick Balaska] Re: render differences in github/head and 3.7 [3770 days 19 hours and 36 minutes ago]

Thu, 10 Dec 2015 21:21:57 GMT

In article <5669d15b$1@news.povray.org>, ano### [at] anonymousorg says...

> Bu... wha... hey, wait!
> Mind giving me the exact details of the texture you're having problems
> with? Still want to get down to the heart of the matter.

I was a little hasty with the 'send' button before because I wanted to 
mention I didn't think you'd want such variance between 3.7.0 and 3.7.1

It's the Jade pigment in textures.inc.  I also noticed it with 
Apocolypse.
Oddly, I also use Blood_Marble and Blue_Sky3 and those seem fine.

I'm gonna go out on a limb and say this scene gives different results 
for all versions of 3.7.0 vs. 3.7.1.

// PoVRay 3.7 Scene File " ... .pov"
// author:  ...
// date:    ...
//---------------------------------------------------------------------
#version 3.7;
global_settings{ assumed_gamma 1.0 }
global_settings {
        noise_generator 1 // or 2 or 3
}
//---------------------------------------------------------------------
#include "colors.inc"
#include "textures.inc"
//---------------------------------------------------------------------
// camera 
------------------------------------------------------------------
#declare Camera_0 = camera {perspective angle 75        // front view
                            location  <0.0 , 1.0 ,-3.0>
                            right     x*image_width/image_height
                            look_at   <0.0 , 1.0 , 0.0>}
camera{Camera_0}
// sun 
----------------------------------------------------------------------
light_source{< 3000,3000,-3000> color White}
// sky 
----------------------------------------------------------------------
sky_sphere { pigment { gradient <0,1,0>
                       color_map { [0.00 rgb <0.6,0.7,1.0>]
                                   [0.35 rgb <0.1,0.0,0.8>]
                                   [0.65 rgb <0.1,0.0,0.8>]
                                   [1.00 rgb <0.6,0.7,1.0>] 
                                 } 
                       scale 2         
                     }
           }
// ground 
-------------------------------------------------------------------
plane{ <0,1,0>, 0 
       texture{ pigment{ checker color rgb<1,1,1>*1.2 color rgb
<0.25,0.15,0.1>*0}
                finish { phong 0.1}
              }
     }
//----------------------------------------------------------------------
//---------------------------- objects in scene ------------------------
//----------------------------------------------------------------------

// sample sphere
sphere { <0,1.5,0>, 1.00 
	texture {
		pigment {Jade}
	}
       }

[clipka] Re: render differences in github/head and 3.7 [3770 days 21 hours and 34 minutes ago]

Thu, 10 Dec 2015 19:24:11 GMT

Am 10.12.2015 um 19:25 schrieb Dick Balaska:

>> in other
>> words, you might have messed up the build somehow.
> 
> How dare you sir!
> 
> (Open povray.sln. 'F8'  -- How can I mess that up? ;)  You did a fine 
> job putting that together)

Glad to hear that :)

>> Just a hunch, but it might be related to the noise generator.
>>
>> One thing you could try is to set
>>
>>     global_settings {
>>         noise_generator 1 // or 2 or 3
>>     }
> 
> Hey that's cool.  I can see it changing the output, but it doesn't help.
> 
> I grabbed 
> povray-3.7.1-alpha.8358383-av65-Win64.7z
> and it does generate the same output as my homebrew
>        3.7.1-alpha.8353331.unofficial.msvc
> 
> So, my path to success is to now build that version of source code for 
> Linux (groan).

Bu... wha... hey, wait!
Mind giving me the exact details of the texture you're having problems
with? Still want to get down to the heart of the matter.

[Dick Balaska] Re: render differences in github/head and 3.7 [3770 days 22 hours and 32 minutes ago]

Thu, 10 Dec 2015 18:25:50 GMT

In article <56696005$1@news.povray.org>, ano### [at] anonymousorg says...
> 
> Am 10.12.2015 um 07:04 schrieb Dick Balaska:
> > In article <5668c3c7$1@news.povray.org>, ano### [at] anonymousorg says...

> in other
> words, you might have messed up the build somehow.

How dare you sir!

(Open povray.sln. 'F8'  -- How can I mess that up? ;)  You did a fine 
job putting that together)

> Just a hunch, but it might be related to the noise generator.
> 
> One thing you could try is to set
> 
>     global_settings {
>         noise_generator 1 // or 2 or 3
>     }

Hey that's cool.  I can see it changing the output, but it doesn't help.

I grabbed 
povray-3.7.1-alpha.8358383-av65-Win64.7z
and it does generate the same output as my homebrew
       3.7.1-alpha.8353331.unofficial.msvc

So, my path to success is to now build that version of source code for 
Linux (groan).

Thanks for your help!

dik

[clipka] Re: render differences in github/head and 3.7 [3771 days 5 hours and 37 minutes ago]

Thu, 10 Dec 2015 11:20:37 GMT

Am 10.12.2015 um 07:04 schrieb Dick Balaska:
> In article <5668c3c7$1@news.povray.org>, ano### [at] anonymousorg says...
>>
>> If you're worried about the quality of your build, you may want to
>> compare it to the latest semi-official development build of the master
>> branch, which can be found at https://github.com/c-lipka/povray/releases.
>>
> Qu'est-ce que c'est "quality of the build"?

What is "Qu'est-ce que c'est"?
(just kidding ;))

What I mean is, apparently you've built that "povdos" version yourself,
so there is a (slim) chance that the reason for the differences you're
seeing are not actually due to differences in the code, but due to
differences in the build settings or the build process itself; in other
words, you might have messed up the build somehow.


> 	texture {
> 		pigment {Jade}
> 		finish {
> 			ambient 0.3
> 			reflection 0.05
> 			diffuse 0.7
> 			roughness 0.3
> 		}
> 		scale 5*inches
> 	}
> looks completely different.  It smells like the povdos version is 
> ignoring the scale 5*inches.  I definitely have to RCA this.
> 
> linux http://www.buckosoft.com/~dick/t/tteo2021.png
> vs.
> povdos http://www.buckosoft.com/~dick/t/tteo2033.png

Just a hunch, but it might be related to the noise generator.

One thing you could try is to set

    global_settings {
        noise_generator 1 // or 2 or 3
    }

and see if that makes the scene look the same with both versions.

Also, some builds of POV-Ray provide a special optimized implementation
of the noise generator on CPUs that support certain AMD instruction set
extensions. Maybe that optimized noise generator doesn't give the same
results as the canonical one.

[Dick Balaska] Re: render differences in github/head and 3.7 [3771 days 10 hours and 53 minutes ago]

Thu, 10 Dec 2015 06:04:26 GMT

In article <5668c3c7$1@news.povray.org>, ano### [at] anonymousorg says...
> 
> If you're worried about the quality of your build, you may want to
> compare it to the latest semi-official development build of the master
> branch, which can be found at https://github.com/c-lipka/povray/releases.
> 
Qu'est-ce que c'est "quality of the build"?

> Also, Linux builds frequently use different mathematical precision than
> Windows builds (and there may also be differences between the Windows
> plain 32 bit builds on one hand, and the 32 bit SSE2 and 64 bit builds
> on the other hand), which in some rare cases might produce noticeable
> differences in the output.

Ah poo.

That Apocolypse pigment was a tiny background object and I wasn't 
*really* concerned [1], but I just noticed one of my foreground objects
	texture {
		pigment {Jade}
		finish {
			ambient 0.3
			reflection 0.05
			diffuse 0.7
			roughness 0.3
		}
		scale 5*inches
	}
looks completely different.  It smells like the povdos version is 
ignoring the scale 5*inches.  I definitely have to RCA this.

linux http://www.buckosoft.com/~dick/t/tteo2021.png
vs.
povdos http://www.buckosoft.com/~dick/t/tteo2033.png

> 
> 
> That said, there is also a possibility that you've found a bug, and
> therefore I do indeed want to know more about this.

[1] you can't even really tell in the video. But I use an ancient ACDSee 
to flip lossless png files at 18 fps during development, and there it 
was noticable.

[clipka] Re: render differences in github/head and 3.7 [3771 days 16 hours and 44 minutes ago]

Thu, 10 Dec 2015 00:13:59 GMT

Am 09.12.2015 um 23:40 schrieb Dick Balaska:
> So I'm using my custom built povdos on one Windows box and (5) povray-
> 3.7 on linux.
> 
> I notice that
>       texture {pigment { Apocalypse} scale 1*inch}
> renders differently on povdos.
> Should that be the case?  Is github/master/head different than the 
> release version? This is the question before I decide how to proceed.
> I can either build a linux version from head, or switch to a different 
> texture :) Or maybe you (clipka) want to know more about this.

The "master" branch on GitHub is indeed different from the latest
release version (that would be the "stable" branch, or the v3.7.0.0
tag), and includes plenty of improvements and bugfixes over the latest
official rlease, so some differences may be intentional, though I'd
indeed need to know more details in order to give you a more specific reply.

If you're worried about the quality of your build, you may want to
compare it to the latest semi-official development build of the master
branch, which can be found at https://github.com/c-lipka/povray/releases.

Also, Linux builds frequently use different mathematical precision than
Windows builds (and there may also be differences between the Windows
plain 32 bit builds on one hand, and the 32 bit SSE2 and 64 bit builds
on the other hand), which in some rare cases might produce noticeable
differences in the output.


That said, there is also a possibility that you've found a bug, and
therefore I do indeed want to know more about this.

[Dick Balaska] render differences in github/head and 3.7 [3771 days 18 hours and 17 minutes ago]

Wed, 9 Dec 2015 22:40:49 GMT

So I'm using my custom built povdos on one Windows box and (5) povray-
3.7 on linux.

I notice that
      texture {pigment { Apocalypse} scale 1*inch}
renders differently on povdos.
Should that be the case?  Is github/master/head different than the 
release version? This is the question before I decide how to proceed.
I can either build a linux version from head, or switch to a different 
texture :) Or maybe you (clipka) want to know more about this.

dik

[Dick Balaska] Re: Forked for VS2015 [3783 days 8 hours and 53 minutes ago]

Sat, 28 Nov 2015 08:04:14 GMT

In article <MPG.30c27d8f63471b50989685@news.povray.org>, 
dic### [at] buckosoftcom says...
> 
> Woo hoo. I got github/master to build and run, out of the box using 
> VS2015 community edition!
> 
> Now, haha, my renderfarm server program (windows version) doesn't want 
> to talk to my windows client. 
> 
> Inching closer...

I have increased my RenderFarm from 42Ghz to 70Ghz.
http://www.buckosoft.com/bsac/
I'm a pov happy guy :)

As expected my Windows box is about equal to my 4 linux boxes combined.
For a specific set of frames, I get a render time of 8.5 minutes vs.
22, 27, 27, 78 minutes for my linux boxes.

Yeah, that Celeron's pretty slow, but she's my firewall and is otherwise 
pretty idle, so I might as well use it.  Maybe she gets retired from pov 
soon...

dik

[Dick Balaska] Re: Forked for VS2015 [3783 days 20 hours and 58 minutes ago]

Fri, 27 Nov 2015 19:59:41 GMT

In article <56462e27$1@news.povray.org>, ano### [at] anonymousorg says...
> 
> Am 13.11.2015 um 17:05 schrieb Dick Balaska:
> > In article <564526a7$1@news.povray.org>, ano### [at] anonymousorg says...
> >> I've just revived the "console" project, which provides a simple 
> >> console version of POV-Ray for Windows.
> > 
> > Sweet!
> > 
> >> To build it, search the file `windows/povconfig/syspovconfig.h` for the
> >> line reading `// #define _CONSOLE`, and change it to `#define _CONSOLE`,
> >> then build the "console" project instead of the "GUI" project. This will
> >> create a binary named "povconsole64.exe" (presuming you're building the
> >> 64-bit non-debug version).
> > 
> > Er, well I'm still not building anything at the moment. :(
> > Can you dropbox it to me?
> 
> I'm afraid I'm rather short on time these days (that, plus I don't even
> have a dropbox account ;)), so maybe someone else can step in?

Woo hoo. I got github/master to build and run, out of the box using 
VS2015 community edition!

Now, haha, my renderfarm server program (windows version) doesn't want 
to talk to my windows client. 

Inching closer...

dik

[clipka] Re: Compiling 3.7 RC7 with Visual Studio Express... [3797 days 18 hours and 45 minutes ago]

Fri, 13 Nov 2015 22:12:29 GMT

Am 05.06.2013 um 14:03 schrieb scott:
> There are a few steps I needed to take to get this to work correctly.
> This isn't necessarily the best way or the only way, it's simply what I
> did to get it working.
> 
> 1. Open the solution in the windows\vs10 folder with VS Express 2012
> 2. Choose “Update” to update all the projects
> 3. Open the configuration manager, uncheck the Build option for cmedit,
> codemax and console (you'll need to do this for the combination of
> debug/release and 32bit/64bit that you want to build)
> 4. Do a find&replace on all files to replace “boost::shared_ptr” with
> “shared_ptr”
> 5. Do a find&replace on all files to replace “shared_ptr” with
> “boost::shared_ptr”
> 6. Open syspovconfig.h from the VFE\vfewin project and fix line 122
> (gets messed up with steps 4 and 5), it should read #include
> <boost/shared_ptr.hpp>
> 7. Open msvc.h from the VFE\vfewin project and delete the #error on line
> 164 and copy the #defines from the previous #elif in its place (and you
> can change the 10’s to 11’s if you want)
> 8. For the toFloat, eLut and b44ExpLogTable projects under OpenEXR
> Libraries; open the project properties and under Custom Build Step set
> Execute After to BscMake
> 9. Open unordered_map.hpp from the Generic POV-Ray\povbackend project
> (it’s under External Dependencies) and add the following #define
> BOOST_NO_0X_HDR_INITIALIZER_LIST at line 11

Just wondering whether anyone is still using Visual Studio Express 2012
and might want to try building the current master branch?

If so, I'd love to know whether you can get away now with performing
only steps 1-3, 7 and 9.

[clipka] Re: Forked for VS2015 [3797 days 22 hours and 19 minutes ago]

Fri, 13 Nov 2015 18:38:31 GMT

Am 13.11.2015 um 17:05 schrieb Dick Balaska:
> In article <564526a7$1@news.povray.org>, ano### [at] anonymousorg says...
>> I've just revived the "console" project, which provides a simple 
>> console version of POV-Ray for Windows.
> 
> Sweet!
> 
>> To build it, search the file `windows/povconfig/syspovconfig.h` for the
>> line reading `// #define _CONSOLE`, and change it to `#define _CONSOLE`,
>> then build the "console" project instead of the "GUI" project. This will
>> create a binary named "povconsole64.exe" (presuming you're building the
>> 64-bit non-debug version).
> 
> Er, well I'm still not building anything at the moment. :(
> Can you dropbox it to me?

I'm afraid I'm rather short on time these days (that, plus I don't even
have a dropbox account ;)), so maybe someone else can step in?

[Dick Balaska] Re: Forked for VS2015 [3798 days and 52 minutes ago]

Fri, 13 Nov 2015 16:05:53 GMT

In article <564526a7$1@news.povray.org>, ano### [at] anonymousorg says...
> I've just revived the "console" project, which provides a simple 
> console version of POV-Ray for Windows.

Sweet!

> To build it, search the file `windows/povconfig/syspovconfig.h` for the
> line reading `// #define _CONSOLE`, and change it to `#define _CONSOLE`,
> then build the "console" project instead of the "GUI" project. This will
> create a binary named "povconsole64.exe" (presuming you're building the
> 64-bit non-debug version).

Er, well I'm still not building anything at the moment. :(
Can you dropbox it to me?
 
> 
> There are a few caveats to it, for instance it doesn't automatically
> read any master .ini file, nor will it be able to automatically locate
> the default include files, so you'll have to specify some additional
> command-line options to work around this. Also, it doesn't seem to do a
> good job at guessing how many cores you have, so you may want to use the
> "+wt" command-line setting to manually specify the number of threads to use.

[clipka] Re: Forked for VS2015 [3798 days 17 hours and 3 minutes ago]

Thu, 12 Nov 2015 23:54:15 GMT

Am 30.10.2015 um 06:58 schrieb Dick Balaska:

> [1] I *really* want to get povdos going.  I have a 4 linux box 
> renderfarm. My windows box is about 50% faster at povray than those 4 
> boxes _combined_. (All praise to whoever added SMP to povray.)


I've just revived the "console" project, which provides a simple console
version of POV-Ray for Windows.

To build it, search the file `windows/povconfig/syspovconfig.h` for the
line reading `// #define _CONSOLE`, and change it to `#define _CONSOLE`,
then build the "console" project instead of the "GUI" project. This will
create a binary named "povconsole64.exe" (presuming you're building the
64-bit non-debug version).


There are a few caveats to it, for instance it doesn't automatically
read any master .ini file, nor will it be able to automatically locate
the default include files, so you'll have to specify some additional
command-line options to work around this. Also, it doesn't seem to do a
good job at guessing how many cores you have, so you may want to use the
"+wt" command-line setting to manually specify the number of threads to use.

[clipka] Re: Forked for VS2015 [3798 days 18 hours and 4 minutes ago]

Thu, 12 Nov 2015 22:53:22 GMT

FYI, I've just checked in some updates to POV-Ray to improve
compatibility with Visual Studio 2015. According to my own tests, the
official VS 2010 projects should now build flawlessly after automatic
conversion to VS 2015.


The pre-packaged version of the OpenEXR library turned out to contain an
issue that does not affect VS 2010, but causes compile errors with VS
2015. This was solved by upgrading to the latest stable version (2.2.0).
I've also changed the eLut and toFloat projects' custom build steps to
run after the Link step now, rather than the Manifest step that turned
out to cause trouble with VS 2015. The h44LogExpTable project, which
also included a post-Manifest build step, has been dropped entirely, as
the file it would generate is part of the official OpenEXR source
package anyway.

The pre-packaged version of boost also turned out to be problematic, as
it didn't provide a useful compile-time configuration for VS 2015, so
I've upgraded it to the latest stable version (1.59.0) as well. This
turned out to be incompatible with our attempts to suppress VS 2010's
C++0x features, but changing the project settings to re-enable C++0x
showed no ill effects with the current code, so that's what I've done.

There was one last boost-related issue with VS 2015, stemming from the
fact that we were using one and the same .cpp file to generate the
precompiled headers for multiple statically linked libraries (see
https://connect.microsoft.com/VisualStudio/feedback/details/1260338 for
details of this known quirk); to solve this, each library now has its
own dedicated .cpp file for precompiled header generation.

The only other thing left to do was add settings for VS 2015 to
POV-Ray's compile-time configuration.


Given how flawlessly the VS 2010 projects now seem to compile on VS 2015
after automatic conversion, I guess we'll refrain from including
official VS 2015 projects for a while longer. This way we won't have to
worry about the projects for the different versions getting out of sync,
e.g. when new source files are added.

[Dick Balaska] Re: Forked for VS2015 [3812 days 10 hours and 59 minutes ago]

Fri, 30 Oct 2015 05:58:54 GMT

In article <56016377$1@news.povray.org>, ben### [at] outlookcom 
says...
> 
> For anyone interested in following along,

Me! [1]

> I forked POV-Ray and created a 
> new branch targeted just at getting it to compile in VS2015. The fork is 
> here:
> https://github.com/BenjaminChambers/povray/tree/VS2015

Good.  It is not possible to even get a copy of vs10, so a newbie is out 
of luck trying to build.

> 
> I copied the directory windows/vs10 to windows/vs2015. That way, it will 
> continue to compile with previous versions. I then re-targeted all 
> included project files.

Don't you need povray.sln? It is missing.

> 
> My first attempts are to get the ancillary libraries compiling correctly.

It looks like all you did was fix toFloat.h.  I was hoping you'd be 
further along.  I've already hacked in the missing million boost_ptr:: 
in 2 non-functional workspaces.
> 
> Both the Boost libraries give errors, as do the OpenEXR libraries. The 
> jpeg, libpng, tiff, and zlib projects all compile (apparently) correctly.
> 
> For Boost and OpenEXR, I'm going to go to the source and download new 
> versions, then work to integrate them in the current directory structure 
> as it is now. However, is there any reason they aren't simply excluded 
> from the source, with a note that they are dependencies?

dik

[1] I *really* want to get povdos going.  I have a 4 linux box 
renderfarm. My windows box is about 50% faster at povray than those 4 
boxes _combined_. (All praise to whoever added SMP to povray.)

[Benjamin Chambers] Re: toFloat.h missing [3844 days 17 hours and 32 minutes ago]

Sun, 27 Sep 2015 23:25:56 GMT

I finally got the custom build step to generate the header as needed. 
I'm not sure which change made it, but what I did in the end to was to 
create a new project file, set it to run after link (instead of 
manifest), and set an Additional Dependency of $(TargetPath).

We'll see as I work with the other header-generating projects which 
change (or combination of them) was necessary.

[Benjamin Chambers] Re: toFloat.h missing [3847 days 17 hours and 46 minutes ago]

Thu, 24 Sep 2015 23:11:52 GMT

On 9/24/2015 4:17 PM, clipka wrote:
> Am 24.09.2015 um 23:55 schrieb Benjamin Chambers:
>> On 9/24/2015 1:44 PM, clipka wrote:
>>> As far as this is concerned, while testing with VS2010 I just noticed
>>> that the description ("Creating toFloat.h..." or whatever) isn't
>>> actually printed to the build output even if the custom build step
>>> obviously runs (as demonstrated by toFloat.h reappearing after having
>>> been deleted).
>>>
>>> A hint that the custom build step was run seems to be a log file
>>> generated in "build\toFloat\x64\Release" (in case of building for x64),
>>> named "toFloat.write.1.tlog".
>>>
>>> If you can't get the Custom Build Step mechanism to do the job, you
>>> might want to try the Post-Build Event mechanism instead, though IIRC
>>> there was /something/ undesirable about it.
>>
>> I've tried both, actually, and neither one indicates in the log file
>> that the step was run, nor do they generate the header file.
>
> That's certainly strange. It does build the .exe that's supposed to
> generate them, right?
>

Yes, and I ran it from the command line to generate the necessary headers.

There may be something odd with my specific installation causing this issue.

[clipka] Re: toFloat.h missing [3847 days 18 hours and 40 minutes ago]

Thu, 24 Sep 2015 22:18:00 GMT

Am 24.09.2015 um 23:55 schrieb Benjamin Chambers:
> On 9/24/2015 1:44 PM, clipka wrote:
>> As far as this is concerned, while testing with VS2010 I just noticed
>> that the description ("Creating toFloat.h..." or whatever) isn't
>> actually printed to the build output even if the custom build step
>> obviously runs (as demonstrated by toFloat.h reappearing after having
>> been deleted).
>>
>> A hint that the custom build step was run seems to be a log file
>> generated in "build\toFloat\x64\Release" (in case of building for x64),
>> named "toFloat.write.1.tlog".
>>
>> If you can't get the Custom Build Step mechanism to do the job, you
>> might want to try the Post-Build Event mechanism instead, though IIRC
>> there was /something/ undesirable about it.
> 
> I've tried both, actually, and neither one indicates in the log file
> that the step was run, nor do they generate the header file.

That's certainly strange. It does build the .exe that's supposed to
generate them, right?

[Benjamin Chambers] Re: toFloat.h missing [3847 days 19 hours and 2 minutes ago]

Thu, 24 Sep 2015 21:55:44 GMT

On 9/24/2015 1:44 PM, clipka wrote:
> As far as this is concerned, while testing with VS2010 I just noticed
> that the description ("Creating toFloat.h..." or whatever) isn't
> actually printed to the build output even if the custom build step
> obviously runs (as demonstrated by toFloat.h reappearing after having
> been deleted).
>
> A hint that the custom build step was run seems to be a log file
> generated in "build\toFloat\x64\Release" (in case of building for x64),
> named "toFloat.write.1.tlog".
>
> If you can't get the Custom Build Step mechanism to do the job, you
> might want to try the Post-Build Event mechanism instead, though IIRC
> there was /something/ undesirable about it.

I've tried both, actually, and neither one indicates in the log file 
that the step was run, nor do they generate the header file.

[clipka] Re: toFloat.h missing [3847 days 21 hours and 13 minutes ago]

Thu, 24 Sep 2015 19:44:51 GMT

Am 24.09.2015 um 18:29 schrieb Benjamin Chambers:

> Now this is interesting. I've been over the XML for the project files,
> and they APPEAR to be set up correctly to generate the header files.
> 
> However, the custom build step never runs.

As far as this is concerned, while testing with VS2010 I just noticed
that the description ("Creating toFloat.h..." or whatever) isn't
actually printed to the build output even if the custom build step
obviously runs (as demonstrated by toFloat.h reappearing after having
been deleted).

A hint that the custom build step was run seems to be a log file
generated in "build\toFloat\x64\Release" (in case of building for x64),
named "toFloat.write.1.tlog".

If you can't get the Custom Build Step mechanism to do the job, you
might want to try the Post-Build Event mechanism instead, though IIRC
there was /something/ undesirable about it.

[Benjamin Chambers] Re: toFloat.h missing [3847 days 21 hours and 23 minutes ago]

Thu, 24 Sep 2015 19:34:49 GMT

On 9/24/2015 1:22 PM, clipka wrote:
> Just a hunch:
>
> - Could it be due to the fact that (at least in the vs2010 projects) the
> information for the respective custom build step is split across two
> separate <CustomBuildStep> tags?

Manually combining the tags in the project file had no effect.

> - Could it be that the custom build step does run after all, but doesn't
> work properly because it contains an output redirection and the VS2015
> build system somehow fails to handle this properly?

Removing the redirect still doesn't run the custom build step.

I've posted in the MSDN forums, asking if anyone knows why it wouldn't 
run, but haven't received an answer yet. In the meantime, I'll manually 
generate the header files, but this is something that needs to be sorted 
out eventually...

[clipka] Re: toFloat.h missing [3847 days 21 hours and 36 minutes ago]

Thu, 24 Sep 2015 19:22:06 GMT

Am 24.09.2015 um 18:29 schrieb Benjamin Chambers:

> Now this is interesting. I've been over the XML for the project files,
> and they APPEAR to be set up correctly to generate the header files.
> 
> However, the custom build step never runs.
> 
> I'll keep poking around in it and see what I can do.

Just a hunch:

- Could it be due to the fact that (at least in the vs2010 projects) the
information for the respective custom build step is split across two
separate <CustomBuildStep> tags?

- Could it be that the custom build step does run after all, but doesn't
work properly because it contains an output redirection and the VS2015
build system somehow fails to handle this properly?

[clipka] Re: toFloat.h missing [3847 days 21 hours and 53 minutes ago]

Thu, 24 Sep 2015 19:04:36 GMT

Oh, btw, I totally forgot: There's a third file that is created by the
OpenEXR build process on the fly,
"libraries/openexr/IlmImf/b44ExpLogTable.h", so make sure to take care
of that one as well.

[Benjamin Chambers] Re: toFloat.h missing [3848 days and 29 minutes ago]

Thu, 24 Sep 2015 16:28:58 GMT

On 9/18/2015 12:07 PM, Benjamin Chambers wrote:
> On 9/18/2015 10:26 AM, clipka wrote:
>> Make sure that the project conversion from VS2010 to VS2015 has kept the
>> build dependencies and custom build steps intact; rebuilding the "Half"
>> project should automatically trigger a rebuild of the "eLut" and
>> "toFloat" projects first; those projects should in turn cause those
>> files to be created in the "libraries/ilmbase/Half" directory (unless
>> the respective file already exists and is up to date), which should be
>> accompanied by the build log output "Generating <filename>...".
>
> Thanks! This seems to be what the problem is. Here is the output from
> building toFloat:
> 1>------ Rebuild All started: Project: toFloat, Configuration: Release
> x64 ------
> 1>  toFloat.cpp
> 1>  openexr_toFloat.vcxproj ->
>
C:\Users\benja\Source\Repos\povray\windows\vs10\build\toFloat\x64\Release\toFloat.exe
>
> ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Now this is interesting. I've been over the XML for the project files, 
and they APPEAR to be set up correctly to generate the header files.

However, the custom build step never runs.

I'll keep poking around in it and see what I can do.

[Benjamin Chambers] Re: Forked for VS2015 [3848 days 20 hours and 30 minutes ago]

Wed, 23 Sep 2015 20:28:12 GMT

On 9/23/2015 10:13 AM, clipka wrote:
> Am 23.09.2015 um 14:55 schrieb Benjamin Chambers:
>
>> Given that package managers are pretty much ubiquitous in software
>> development (even Visual Studio has Nuget, which has served me quite
>> well in my {admittedly limited} needs), it may be time to rethink this.
>
> While package managers may be /becoming/ more common right now in the
> Windows world, there seem to be fundamental differences; for one, in the
> Unix world package management includes distribution of libraries in
> binary form, whereas NuGet seems to operate on the source code level.

I've seen both, actually. SQLite-Net, for instance, injects source 
directly into your project. Most libraries seem to distribute binaries 
though.

> As for being "ubiquitous", there's still quite a way to go; I don't know
> about VS 2015, but in VS 2010 NuGet wasn't an integral part, and people
> still use that version out in the wild.

Fair enough. In newer versions of Visual Studio, both package 
maintenance through Nuget and source control through Github are more 
tightly integrated. However, your point about VS2010 being still rather 
common stands.

[clipka] Re: Forked for VS2015 [3849 days and 44 minutes ago]

Wed, 23 Sep 2015 16:13:51 GMT

Am 23.09.2015 um 14:55 schrieb Benjamin Chambers:

> Given that package managers are pretty much ubiquitous in software
> development (even Visual Studio has Nuget, which has served me quite
> well in my {admittedly limited} needs), it may be time to rethink this.

While package managers may be /becoming/ more common right now in the
Windows world, there seem to be fundamental differences; for one, in the
Unix world package management includes distribution of libraries in
binary form, whereas NuGet seems to operate on the source code level.

As for being "ubiquitous", there's still quite a way to go; I don't know
about VS 2015, but in VS 2010 NuGet wasn't an integral part, and people
still use that version out in the wild. Also, the ready availability of
libraries still seems to be wanting, for instance according to NuGet's
web page there's no OpenEXR package yet. There's also the issue of
maintenance: Are the packages on NuGet guaranteed to be properly
maintained? By whom? In the Unix world, this is clearly the
responsibility of distro managers. Speaking of which, in the Unix world
you also have a long tradition of simply refering to your distro for
virtually all your package needs; how this will play out in the Windows
world - whether NuGet.org will advance to such a single point of
reference, or whether things will remain more spread out - is yet to be
seen.


Maintaining POV-Ray is a long-term task with limited manpower, and it's
no use exhausting ourselves by keeping up the pace with all the latest
and greatest trends in software development. We'll leave that up to
people who do shorter-term projects, see how that plays out for them,
and adopt whatever comes out as tried, tested and well-established good
practice.

No offense there; it's just the way we roll - need to roll - in POV-Ray
development.

[Benjamin Chambers] Re: Forked for VS2015 [3849 days 4 hours and 2 minutes ago]

Wed, 23 Sep 2015 12:55:47 GMT

On 9/22/2015 11:09 AM, clipka wrote:
> A quick note though: According to tradition we would probably have named
> the directory "vs14", after Visual Studio's internal version number.

IMO, whatever makes things easier.

If we get to the point where my work is being committed to the original 
branch, and you ask me to rename the directory, I'll rename it. But 
given that I always have to look up which version number goes with which 
version of VS, I'll leave it as it is for now.

>> However, is there any reason they aren't simply excluded
>> from the source, with a note that they are dependencies?
>
> Yes, there is absolutely a reason. Two actually:
>
> The first reason is historic. Before the advent of the World Wide Web,
> and even during its early days, getting hold of 3rd party libraries used
> to be quite a challenge (except on Unix systems, where package
> management has a long tradition, whereas in the DOS and Windows world it
> is still unheard of to this day); so to allow non-Unix users to build
> their own version easily, the POV-Ray source code packages for those
> systems have traditionally always come with source code for all the 3rd
> party libraries POV-Ray could make use of.

Given that package managers are pretty much ubiquitous in software 
development (even Visual Studio has Nuget, which has served me quite 
well in my {admittedly limited} needs), it may be time to rethink this.

However, my first goal is simply to get POV to compile using the new 
tools, so that's a goal for another day.

> Case in point, the official OpenEXR build process turned out to be so
> notoriously difficult to get right, that for quite a while during the
> development of POV-Ray 3.7, OpenEXR support was disabled by default in
> the official POV-Ray source package for Windows, and even some
> developers chose to not bother trying to enable OpenEXR support in their
> development builds.
>
> Boost, too, has been difficult to build properly. It may be no
> coincidence that to this date the boost thread and system libraries keep
> causing trouble even in POV-Ray's Unix build process.

Yes, I've already noticed this from working with them yesterday.

I'll roll back to the versions included with the POV source, and just 
work on getting the project files set up correctly. It may be necessary 
for me to install VS2010 so I can compare, but I'll try to do it by 
reading the original vcxproj files instead.

[clipka] Re: Forked for VS2015 [3849 days 23 hours and 49 minutes ago]

Tue, 22 Sep 2015 17:09:09 GMT

Am 22.09.2015 um 16:19 schrieb Benjamin Chambers:
> For anyone interested in following along, I forked POV-Ray and created a
> new branch targeted just at getting it to compile in VS2015. The fork is
> here:
> https://github.com/BenjaminChambers/povray/tree/VS2015
> 
> I copied the directory windows/vs10 to windows/vs2015. That way, it will
> continue to compile with previous versions.

And that's the proper approach.

A quick note though: According to tradition we would probably have named
the directory "vs14", after Visual Studio's internal version number.

Then again, those internal version numbers are prone to leading to
confusion, so maybe "vs2015" isn't such a bad name after all.


> For Boost and OpenEXR, I'm going to go to the source and download new
> versions, then work to integrate them in the current directory structure
> as it is now.

It would be great if you could avoid that, and use the same versions
currently included in the POV-Ray source package.

> However, is there any reason they aren't simply excluded
> from the source, with a note that they are dependencies?

Yes, there is absolutely a reason. Two actually:

The first reason is historic. Before the advent of the World Wide Web,
and even during its early days, getting hold of 3rd party libraries used
to be quite a challenge (except on Unix systems, where package
management has a long tradition, whereas in the DOS and Windows world it
is still unheard of to this day); so to allow non-Unix users to build
their own version easily, the POV-Ray source code packages for those
systems have traditionally always come with source code for all the 3rd
party libraries POV-Ray could make use of.

The second reason is still valid today, but has the same roots, namely
that we want POV-Ray to be reasonably easy to build.

When work started on POV-Ray 3.7, the old tradition of shipping all 3rd
party libraries' source code was in fact originally not continued, most
likely primarily because the newly added boost and OpenEXR libraries
were deemed simply too large to include.

However, from our experience, building 3rd party libraries in Windows
environments per se, and more so in a manner that is compatible with the
POV-Ray build process, typically ranges from "non-trivial" to "a major
PITA", to the point that it can no longer be expected from interested
users to go through that hassle.

Case in point, the official OpenEXR build process turned out to be so
notoriously difficult to get right, that for quite a while during the
development of POV-Ray 3.7, OpenEXR support was disabled by default in
the official POV-Ray source package for Windows, and even some
developers chose to not bother trying to enable OpenEXR support in their
development builds.

Boost, too, has been difficult to build properly. It may be no
coincidence that to this date the boost thread and system libraries keep
causing trouble even in POV-Ray's Unix build process.

This was deemed unacceptable in the long run, so ultimately an endeavor
was made to set up our own set of Visual Studio projects to replicate
the OpenEXR build process; as thise projects are obviously only
guaranteed to properly work with one particular version of the
respective 3rd party library, the respective source code is now shipped
along after all - albeit only the subset required to build POV-Ray.


If this is a point you can agree with, then I would kindly ask you to
try setting up the Visual Studio 2015 build process to work with the
library versions currently provided with POV-Ray, so that your work
might be easily integrated into the official POV-Ray distribution.

If on the other hand you do not agree with this point, it would only be
logical to not replace that source code either, but instead set up the
Visual Studio 2015 build process to make use of official source packages
of the 3rd party libraries, ideally in a manner that their place of
residence doesn't collide with the existing official POV-Ray source
tree. That, too, would allow for re-integration of your work into
official POV-Ray.

[Benjamin Chambers] Forked for VS2015 [3850 days 2 hours and 38 minutes ago]

Tue, 22 Sep 2015 14:19:35 GMT

For anyone interested in following along, I forked POV-Ray and created a 
new branch targeted just at getting it to compile in VS2015. The fork is 
here:
https://github.com/BenjaminChambers/povray/tree/VS2015

I copied the directory windows/vs10 to windows/vs2015. That way, it will 
continue to compile with previous versions. I then re-targeted all 
included project files.

My first attempts are to get the ancillary libraries compiling correctly.

Both the Boost libraries give errors, as do the OpenEXR libraries. The 
jpeg, libpng, tiff, and zlib projects all compile (apparently) correctly.

For Boost and OpenEXR, I'm going to go to the source and download new 
versions, then work to integrate them in the current directory structure 
as it is now. However, is there any reason they aren't simply excluded 
from the source, with a note that they are dependencies?

[Benjamin Chambers] Re: toFloat.h missing [3850 days 3 hours and 8 minutes ago]

Tue, 22 Sep 2015 13:49:37 GMT

On 9/21/2015 1:03 AM, scott wrote:
>> I'll take a look at the VS2010 project files, and see if I can set up
>> the VS2015 projects accordingly.
>
> I posted some instructions a (long) while back on how to get it to work
> on VS Express, I had the same issues initially so some of those steps I
> posted might help you out.
>
>

I read through that before I started, and many of the changes you detail 
no longer apply. However, I'm referring to it often as I work.

I forked a new branch today focused on getting it to compile in VS2015. 
That way, I can keep all of my work separate.

[scott] Re: toFloat.h missing [3851 days 9 hours and 54 minutes ago]

Mon, 21 Sep 2015 07:03:31 GMT

> I'll take a look at the VS2010 project files, and see if I can set up
> the VS2015 projects accordingly.

I posted some instructions a (long) while back on how to get it to work 
on VS Express, I had the same issues initially so some of those steps I 
posted might help you out.

[Benjamin Chambers] Re: toFloat.h missing [3853 days 22 hours and 51 minutes ago]

Fri, 18 Sep 2015 18:07:04 GMT

On 9/18/2015 10:26 AM, clipka wrote:
> Make sure that the project conversion from VS2010 to VS2015 has kept the
> build dependencies and custom build steps intact; rebuilding the "Half"
> project should automatically trigger a rebuild of the "eLut" and
> "toFloat" projects first; those projects should in turn cause those
> files to be created in the "libraries/ilmbase/Half" directory (unless
> the respective file already exists and is up to date), which should be
> accompanied by the build log output "Generating <filename>...".

Thanks! This seems to be what the problem is. Here is the output from 
building toFloat:
1>------ Rebuild All started: Project: toFloat, Configuration: Release 
x64 ------
1>  toFloat.cpp
1>  openexr_toFloat.vcxproj -> 
C:\Users\benja\Source\Repos\povray\windows\vs10\build\toFloat\x64\Release\toFloat.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

And for eLut:
1>------ Rebuild All started: Project: eLut, Configuration: Release x64 
------
1>  eLut.cpp
1>  openexr_eLut.vcxproj -> 
C:\Users\benja\Source\Repos\povray\windows\vs10\build\eLut\x64\Release\eLut.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

I'll take a look at the VS2010 project files, and see if I can set up 
the VS2015 projects accordingly.

[clipka] Re: toFloat.h missing [3854 days and 31 minutes ago]

Fri, 18 Sep 2015 16:26:53 GMT

Am 17.09.2015 um 00:11 schrieb Benjamin Chambers:
> On 9/16/2015 4:10 PM, Benjamin Chambers wrote:
>> So it looks like I could get around this by using the OpenEXR library,
>> correct?
> 
> Oh geez, brain fart. Either path references "toFloat.h"

"toFloat.h" file is part of the "ilmbase" library (just like
"half.cpp"), which in turn is indeed a part of the OpenEXR library.
("ilm" is an acronym for "Industrial Light & Magic", the company that
originally developed the OpenEXR file format and still maintains the
library.)

What's special about "toFloat.h" (and also "eLut.h") is that these two
files are not part of the library's source file package, but are created
as part of the build process (presumably because their contents are
platform-specific).

Make sure that the project conversion from VS2010 to VS2015 has kept the
build dependencies and custom build steps intact; rebuilding the "Half"
project should automatically trigger a rebuild of the "eLut" and
"toFloat" projects first; those projects should in turn cause those
files to be created in the "libraries/ilmbase/Half" directory (unless
the respective file already exists and is up to date), which should be
accompanied by the build log output "Generating <filename>...".

[Benjamin Chambers] Re: toFloat.h missing [3855 days 18 hours and 46 minutes ago]

Wed, 16 Sep 2015 22:11:53 GMT

On 9/16/2015 4:10 PM, Benjamin Chambers wrote:
> So it looks like I could get around this by using the OpenEXR library,
> correct?

Oh geez, brain fart. Either path references "toFloat.h"

[Benjamin Chambers] Re: toFloat.h missing [3855 days 18 hours and 47 minutes ago]

Wed, 16 Sep 2015 22:10:49 GMT

On 9/16/2015 2:41 PM, Cousin Ricky wrote:
> Benjamin Chambers <ben### [at] outlookcom> wrote:
>> So I'm trying to compile the source with VS2015, and the very first
>> error I find is that the file "toFloat.h" is missing.
>>
>> I cannot find this file anywhere in the source; is it meant to be
>> auto-generated somehow?
>
> That file isn't even /referenced/ anywhere in the source.  Could there be a
> problem with your VS setup?
>
>
>
povray\libraries\ilmbase\Half\half.cpp:
   #if defined (OPENEXR_DLL)
   __declspec(dllexport) half::uif _toFloat[1 << 16] =
       #include "toFloat.h"
   __declspec(dllexport) unsigned short _eLut[1 << 9] =
       #include "eLut.h"
   #else
   const half::uif half::_toFloat[1 << 16] =
       #include "toFloat.h"
   const unsigned short half::_eLut[1 << 9] =
       #include "eLut.h"
   #endif

So it looks like I could get around this by using the OpenEXR library, 
correct?

[Cousin Ricky] Re: toFloat.h missing [3855 days 20 hours and 13 minutes ago]

Wed, 16 Sep 2015 20:45:00 GMT

Benjamin Chambers <ben### [at] outlookcom> wrote:
> So I'm trying to compile the source with VS2015, and the very first
> error I find is that the file "toFloat.h" is missing.
>
> I cannot find this file anywhere in the source; is it meant to be
> auto-generated somehow?

That file isn't even /referenced/ anywhere in the source.  Could there be a
problem with your VS setup?

[Benjamin Chambers] toFloat.h missing [3855 days 23 hours and 6 minutes ago]

Wed, 16 Sep 2015 17:51:23 GMT

So I'm trying to compile the source with VS2015, and the very first 
error I find is that the file "toFloat.h" is missing.

I cannot find this file anywhere in the source; is it meant to be 
auto-generated somehow?

[clipka] Re: Compiling 3.7 RC7 with Visual Studio Express... [3903 days and 41 minutes ago]

Fri, 31 Jul 2015 16:16:45 GMT

Am 13.07.2015 um 19:41 schrieb atlaste:

> I guess that a better solution would be to use a #define with a namespace based
> on the compiler; still, I didn't really feel like making such a huge change
> yesterday.

I'm sure that's the right way to go though.

> If you browse through my changes, you'll notice that I I haven't changed the
> boost libraries themselves and only changed a handful of things. From the top of
> my mind:
>
> - std::smart_ptr

I guess you mean std::shared_ptr, right?

> - std::vector
> - std::bind, std::placeholder::_*
>
> All of these are well supported iirc, and I've checked the features that are
> used for incompatible use. Still, if you know a better solution than my
> solution, please be my guest.

No, they're not; they're entirely C++11 specific (except for 
std::vector; dunno where you found something else; but let's please keep 
the "std::" out of the code for that one, as it's too frequently used. 
Also, I don't know about std::placeholder; never heard of it before).

["Jörg \"Yadgar\" Bleimann"] Code modification project: geo_mesh object [3904 days 11 hours and 14 minutes ago]

Thu, 30 Jul 2015 05:43:55 GMT

Hi(gh)!

Finally, I succeeded in compiling POV-Ray 3.7-stable... so now I can 
start to think in a more detailed way about my modification project.

I want to introduce a new mesh object, the geo_mesh, which is meant to 
be a mesh2 following the curvature of a spherical body, but without 
generating the ASCII code overhead like the current mesh2 object does.

Instead, the geo_mesh object should treat triangles internally like the 
height_field object does - using binary data rather than generating 
ASCII SDL text.

I'm an absolute newbie in POV-Ray code hacking, so I might spend a 
fairly long time in exploring the existing code, notably the parser, 
error handling and height_field definition files.

I already started to think about the syntax for the geo_mesh:

GEO_MESH:
geo_mesh
{
   [GEO_MESH_TYPE] "filename"
   [SW_CORNER] sw
   [NE_CORNER] ne
   [RADIUS] radius
   [LOWEST] lowest
   [HIGHEST] highest
   [VERTICAL_EXAGGERATION] exaggeration
   [GEO_MESH_MODIFIER]
}
GEO_MESH_TYPE:
   ascii | gif | jpeg | png | tga | tiff
SW_CORNER:
   [LATITUDE],[LONGITUDE]
NE_CORNER:
   [LATITUDE],[LONGITUDE]
LATITUDE:
   float value ranging from -90 to 90
LONGITUDE:
   float value ranging from -180 to 180
RADIUS:
   float vector, each value greater than 0; default is <1, 1, 1>
LOWEST:
   float value greater than 0, corresponding to radius; will NOT
   override given values if GEO_MESH_TYPE is "ascii"
HIGHEST:
   float value greater than 0, corresponding to radius; will NOT
   override given values if GEO_MESH_TYPE is "ascii"
VERTICAL_EXAGGERATION
   float value greater than 0, default is 1
GEO_MESH_MODIFIER:
   smooth_triangles

What do you think of the concept?

See you in Khyberspace!

Yadgar

[scott] Re: Compiling 3.7 RC7 with Visual Studio Express... [3920 days 6 hours and 11 minutes ago]

Tue, 14 Jul 2015 10:46:59 GMT

On 25/06/2015 19:23, atlaste wrote:
> scott <sco### [at] scottcom> wrote:
>> There are a few steps I needed to take to get this to work correctly.
>> This isn't necessarily the best way or the only way, it's simply what I
>> did to get it working.
>>
>> [... step 1-9 ...]
>
> Just tried it with VS2013. Still doesn't build, you need a few more steps for
> that. Here's the stuff you need in addition to the earlier steps:

Thanks for that, it prompted me to load up the latest source into VS 
Community Edition 2013.

> 10. Fix msvc.h:
>
>    #elif _MSC_VER >= 1800 && _MSC_VER < 1900
>   #define COMPILER_VER                      ".msvc13"
>   #define METADATA_COMPILER_STRING          "msvc 13"
>    #else
>
> 11. Search for 'using std::min'. Above the 'namespace', add '#include
> <algorithm>'.

I needed to add the #include to ImfHeader.h too otherwise I got lots of 
errors about std::min and std::max.

[atlaste] Re: Compiling 3.7 RC7 with Visual Studio Express... [3920 days 23 hours and 13 minutes ago]

Mon, 13 Jul 2015 17:45:01 GMT

> Wait... what?
>
> There's not a single "boost::tr1" in the code.

Well, yes and no. There a bunch of 'using' statements in the code, that are the
root cause of the issues I had yesterday. I cannot recall the details to be
honest - then again, I also didn't plan for fixing compiler errors for hours on
end. My original intention was to leave it all alone; until my latest port
yesterday that worked just fine here.

Unfortunately, yesterday something changed that made it impossible for me to do
the above 'tricks', due to name conflicts in boost::tr1:: and std:: . Deliberate
or not, the fact is that it didn't work anymore.

I guess that a better solution would be to use a #define with a namespace based
on the compiler; still, I didn't really feel like making such a huge change
yesterday.

If you browse through my changes, you'll notice that I I haven't changed the
boost libraries themselves and only changed a handful of things. From the top of
my mind:

- std::smart_ptr
- std::vector
- std::bind, std::placeholder::_*

All of these are well supported iirc, and I've checked the features that are
used for incompatible use. Still, if you know a better solution than my
solution, please be my guest.

[clipka] Re: Compiling 3.7 RC7 with Visual Studio Express... [3923 days 12 hours and 39 minutes ago]

Sat, 11 Jul 2015 04:18:18 GMT

Am 10.07.2015 um 23:32 schrieb atlaste:

> I've also
> changed a ton of boost::tr1 to std; that's how it should be anyways if you're
> using 'using' throughout the solution.

Wait... what?

There's not a single "boost::tr1" in the code.

If you're referring to the "boost/tr1/*.hpp" include files, and/or the 
use of namespace "tr1::" where C++11 now has the same functionality as 
"std::", - by all means leave them be:

(1) POV-Ray is /not/ written in C++11; it is written in C++03/TR1. 
Consequently, the TR1 functionality should /not/ be accessed via the 
namespace where it resides in C++11, but via the original "tr1::" namespace.

(2) This is a deliberate decision, aimed at providing maximum 
portability. To my knowledge, all contemporary C++11 compilers also 
still support the "tr1::" namespace.

(3) The use of "boost/tr1/*.hpp" instead of the corresponding TR1 header 
files is also deliberate, in order to provide compatibility with pre-TR1 
C++03 compilers. The boost/tr1 header files are stubs that pull in 
either the compiler's own TR1 headers (if available), or map boost's 
implementations of the same functionality into the "tr1::" namespace. 
Likewise, it can be expected that future versions of those header files 
will also pull in from "std::" of any C++11 compilers that cease to 
natively support the "tr1::" namespace.

[atlaste] Re: Compiling 3.7 RC7 with Visual Studio Express... [3923 days 19 hours and 23 minutes ago]

Fri, 10 Jul 2015 21:35:01 GMT

"atlaste" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > I presume you're not actually trying to build RC7 anymore, but some
> > newer version, right?
>
> Yes, latest version.
>
> I'm now in the process of simply forking it and making the changes there;
> otherwise this story will repeat itself every time. I hope to check it in
> somewhere today.

Actually it turned out to be quite a bit more complicated than this
description... :-(

It now works, I've also added a new camera just for the fun of it. I've also
changed a ton of boost::tr1 to std; that's how it should be anyways if you're
using 'using' throughout the solution.

Latest version fork can be found here: https://github.com/atlaste/povray . I'll
make a pull request, hopefully they'll pick it up.

[atlaste] Re: Compiling 3.7 RC7 with Visual Studio Express... [3923 days 21 hours and 18 minutes ago]

Fri, 10 Jul 2015 19:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> I presume you're not actually trying to build RC7 anymore, but some
> newer version, right?

Yes, latest version.

I'm now in the process of simply forking it and making the changes there;
otherwise this story will repeat itself every time. I hope to check it in
somewhere today.