|
 |
Please see the attached tarballs, previous announcements in this forum
and INSTALL.txt for suggestions on compiling and running via wrapper script.
Note. The yuqk_DocAndAid_b55a38d3.tar.gz and
yuqk_Examples_b55a38d3.tar.gz files will be attached to a response to
this posting.
A reminder the yuqk fork is not POV-Ray. As time passes, it's less
likely existing POV-Ray scenes will work without modification.
Note. Those using g++ compiler version 13 or later must add the compiler
flag -fno-finite-math-only, if using the flag -ffast-math.
Note. Those compiling to the c++20 (or later) standard must currently
use the -fno-char8_t compiler flag.
Bill P.
---------------- povray-3.8.0-x.yuqk_b55a38d3.tar.gz April 01, 2025
yuqk R19 v0.6.13.0
Minor syntax checking additions for the #switch directive and related
keywords.
Added support for 2D surface outputs with text{} by using a zero
thickness and the new 'caps' feature.
Added some trial checking of passed text{} and sphere{} identifiers in
the debug build of yuqk. In addition to testing a way to check the type
of passed objects, it prevents potential issues where users might wrap a
general object - not a sphere identifier - with, for example, sphere {
Light00 }. Users running the debugging compile are also prevented from
using text { TextID }, as text{} assignments to IDs are creating an
internal union{} (or optionally in yuqk, a merge{}). In other words, all
text identifiers should be wrapped with object{} after the initial
definition.
Added the keywords 'caps', 'merge' and 'open' to the text{} object. The
'caps' and 'open' keywords implementing what might become general where
objects already support 'open'. Namely, allowing the return of the caps
/ ends or 'sides' of objects separately. The 'merge' keyword creates an
internal merge{} of individual characters rather than a union{} - a
necessary option where any transparency involved.
Fixed a longstanding issue with the offset vector in the text{} object
where the z component was being ignored. The z component support is
necessary where adjacent font characters overlap by design - otherwise
there is no way to avoid coincident surfaces in the resulting text{}
union of individual characters.
Fixed the support for negative thickness settings in the text{} object.
Only the ends or caps were working correctly.
Removed the generation of parse time warnings for experimental and beta
features. The yuqk fork is in total a test lab for potential v4.0 changes.
Added a DocAidScenes directory scene seeWebHexColor.pov.
The tiny internal rotation created and applied within the text{} object
code to avoid axis aligned numerical noise is being removed in this
release as a trial change. It likely makes more sense to make this
numerical-patch be something the user does when needed.
Fixed a bug introduced in the text{} object code during v3.8 code
development which was occasionally causing segment faults / invalid
memory accesses.
Adding the inbuilt function f_kappa_2d() which can be used to mate up
two 2D curves of any kind at (t), if one has access to the first and
second derivatives of both curves.
Adding the inbuilt functions: f_bezier_2d_linear()
f_bezier_2d_quadratic() f_bezier_2d_cubic() f_bezier_2d_quartic() and
f_bezier_2d_quintic().
Better handling for bump_map{} image seams.
Post a reply to this message
Attachments:
Download 'povray-3.8.0-x.yuqk_b55a38d3.tar.gz' (1665 KB)
|
 |
|
 |
William F Pokorny <ano### [at] anonymous org> wrote:
> Please see the attached tarballs, previous announcements in this forum
> and INSTALL.txt for suggestions on compiling and running via wrapper script.
thanks ! I followed the install.txt and...
* it did compile and check on my Ubuntu 24.04 !
*Less so on my Intel Mac OS Big Sur 11.7.10
there a) I had to compile with CXXFLAGS="-std=c++17 -O2" but even then, I got an
error:
CXX vm/fnintern.o
vm/fnintern.cpp:5483:29: error: constexpr variable 'tmpPow2_52' must be
initialized by a constant expression
static constexpr double tmpPow2_52 = std::pow(2.0,52.0);
^ ~~~~~~~~~~~~~~~~~~
And before that a warning:
parser/parser_expressions.cpp:2993:13: warning: enumeration value
'kBlendMapType_Slope' not handled in switch [-Wswitch]
switch (Blend_Type)
^
these warning happen both with Xcode 13.2.1 and brew installed gcc-14
Post a reply to this message
|
 |
|
 |
On 5/14/25 18:17, Mr wrote:
> William F Pokorny <ano### [at] anonymous org> wrote:
>> Please see the attached tarballs, previous announcements in this forum
>> and INSTALL.txt for suggestions on compiling and running via wrapper script.
>
> thanks ! I followed the install.txt and...
>
> * it did compile and check on my Ubuntu 24.04 !
>
> *Less so on my Intel Mac OS Big Sur 11.7.10
>
> there a) I had to compile with CXXFLAGS="-std=c++17 -O2" but even then, I got an
> error:
>
> CXX vm/fnintern.o
> vm/fnintern.cpp:5483:29: error: constexpr variable 'tmpPow2_52' must be
> initialized by a constant expression
> static constexpr double tmpPow2_52 = std::pow(2.0,52.0);
> ^ ~~~~~~~~~~~~~~~~~~
>
> And before that a warning:
> parser/parser_expressions.cpp:2993:13: warning: enumeration value
> 'kBlendMapType_Slope' not handled in switch [-Wswitch]
> switch (Blend_Type)
> ^
>
> these warning happen both with Xcode 13.2.1 and brew installed gcc-14
>
Thanks for the information!
I had some trouble between g++ and clang++ too with what is considered a
valid constexpr; g++ tends to allow more. I'll put that usage on the
list to change to something more basic.
I'm aware of the kBlendMapType_Slope warning. I'm buried in my attempt
at alternate options parsing at the moment, but IIRC there is some funky
stuff going due there traditionally being a couple of blendmap set ups.
One for normal perturbations (blendmap.h ?) and another for value
patterns. They are now both 'sort of' merged in the current pattern.h
pattern.cpp and parsing implementations.
I think the merge (at v3.7 I'd guess) is why there are some commented
entries and an odd value set up in blendmap.h - some enumeration values
are skipped. I looked at it once, but couldn't get my head around a
clean way to sort it in the time I was willing to spend. With the
warning there, things are not really broken as I see it - though
admittedly not pretty.
Bill P.
Post a reply to this message
|
 |