hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > and those.  (have never actually used quick colours)  (inis make using multiple
> > declare=xyz=off type controls easy, I prefer it over having to '#switch' in the
> > scene)
>
> Not immediately apparent to me - maybe you can post an illustrative example
> somewhere at some point.

first off, don't know why I wrote 'xyz=off' which wouldn't work, numbers only,
afaik.  also poorly written, sorry.

off the top of head, any scene which can be used with different sets of constant
values to get corresponding results, like Bruno Cabasson changing the sun's
angle to get differently lit clouds.  these parameter sets, in the scene, are
likely to be inside a '#switch' or an '#if .. #elseif .. #end'.  instead, they
can be placed in an ini, not bloating the scene, and no more editing the scene
if just one value needs adjusting, or a new set of parameters needs adding.

not much of a case but works for me.  (perhaps just some "faulty" wiring in my
brain  ;-))


> > I don't want to sound .. disparaging, but, ime, that's not how it works, you
> > just have to have no alternative (initially, at least).
>
> Sound as disparaging as you want.  I have an ex-wife.  You'd need to struggle to
> register on that logarithmic scale.  ;)  :D

ouch.


> > when (_if_) I get to the point where I can understand and make your code "my
> > own", I plan to replicate the pulleys depicted on the cover of this book:
> > <www.amazon.com/POSIX-4-Programmers-Guide-Programming-World/dp/1565920740>
>
> Well that ought to be easy, though I'll have to see how well-suited what I have
> is for the hanging weight-to-pulley parts.  Most of what I was aiming for was
> drawing "closed" curves, not the "open" or loose-end parts of block and tackle.

yes, I appreciate that.  hence the idea that there should be two distinct
frontend (prisms and pulleys) macros, utilising the existing more or less as
they are.

wrt moving parts, my guess is that the "trick" will be working with (and from
the perspective of?) the full length of the rope/cable, since it needs to look
reasonably realistic when animated.


regards, jr.

Post a reply to this message

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 12/9/19 8:20 PM, also sprach jr:
> > alias nicepov='nice -n 19 povray'
> >
> just fyi, "nice" really doesn't do anything, at least not since the
> invention of multicore CPUs.  The scheduler just picks stuff and goes.
>
> This is an improvement, over where for several years cores could remain
> idle with tasks pending.  Say you've got a normal priority task running
> one thread. It gets dispatched and since there are no other normal
> priority tasks pending, the scheduler is done, even though there are 3
> idle cores and several "low" priority tasks pending.
>
> There is a compile in replacement for the scheduler that fixes the
> current behavior, but the author recommends not using it and waiting for
> his new scheduler, which hopefully Linus will accept into the kernel.
>
> I got no answers to this question ...
> but further research led me to the statements above.

interesting, thanks, and new to me.  I suspect I will simply continue to use it
in aliases and scripts though.

wrt the problem in the question, have you read 'man 7 cpuset'?  no personal
experience, but the reading suggests it should be possible to sort of partition
the system resources and then set up to get the benefit of the "Scheduler load
balancing".


btw, re 'qtpovmodeler', what's with the baseinsertrules.xml file not found?
(same for the docmap xml).  also, and that may be my window manager to blame
(WindowMaker 0.95.7), main menu accelerator key bindings do not work for me.


regards, jr.

Post a reply to this message

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

> yes, I appreciate that.  hence the idea that there should be two distinct
> frontend (prisms and pulleys) macros, utilising the existing more or less as
> they are.

Nope, just need to add one more bit to find a tangent between a point and a
circle.
http://www.ambrsoft.com/TrigoCalc/Circles2/CirclePoint/CirclePointDistance.htm

> wrt moving parts, my guess is that the "trick" will be working with (and from
> the perspective of?) the full length of the rope/cable, since it needs to look
> reasonably realistic when animated.

Seems like Leroy worked most of that out already.

If you could get this to work with that...
http://news.povray.org/povray.binaries.images/thread/%3C3c4d365b%40news.povray.org%3E/

:)  :)  :)

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
> sorry, am getting .. lost in translation.  :-)  is this the same library as
> available on the link below?  if yes, which file(s)?
> ...
> nice site, thanks.  I looked at the lego library posted here, recently, but
> found that to be in .. a not-useful state.  the one from the Dutch site is much
> better, even has documentation!
>
I started with the links to the older version of the library posted by Melody;
Subject: LEGO Library Date: 10 Nov 2019 21:15:01
This older library is for Version 3.1 but contains 4/5 example LEGO models. Out
Of Date - but looked very interesting so I disappeared down the LEGO rabbit
hole. I could be here for some time ....

The new version at the Dutch site is Version 3.7, has changed partnames and
colours, and includes radiosity, for example. Also it contains 4/5 different
examples. E.G. 04551_Crocodile_Engine.   'povray crocodile_engine' invokes the
'crocodile_engine.ini' just fine, output is tga. (Note: edit the pov file to
switch off radiosity or lose the will to live).

Switch to one of the earlier examples (6338_hurricane_harbour) and that's when I
hit the Command Line problem on 3.8: The 6338.ini/6338.pov files cant be called
successfully unless it's 'povray +I6338.pov', which ignores the .ini file
anyway.

Now,the old examples use parts/colours that aren't in the new library and
materials include files, and so will fail to parse anyway. (But I've then
started to edit the model files to use the new partnames/colours and it's nearly
working ...)
My point is that the Command Line call is failing to behave as expected.

Anyway, I'll continue to dig while I'm down this hole.
tery

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > yes, I appreciate that.  hence the idea that there should be two distinct
> > frontend (prisms and pulleys) macros, utilising the existing more or less as
> > they are.
>
> Nope, just need to add one more bit to find a tangent between a point and a
> circle.
> ...
> > wrt moving parts, my guess is that the "trick" will be working with (and from
> > the perspective of?) the full length of the rope/cable, since it needs to look
> > reasonably realistic when animated.
>
> Seems like Leroy worked most of that out already.

yes!  hoping, at some point, to get a look at his code.


> If you could get this to work with that...
> ...
> :)  :)  :)

need to find time to look at those links.  (not this week though.  bought a new
2nd hand machine today, to be used for POV-Ray, pretty much exclusively.  :-))


regards, jr.

Post a reply to this message

hi,

"greytery" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > hi,
> > sorry, am getting .. lost in translation.  :-)  is this the same library as
> > available on the link below?  if yes, which file(s)?
> > ...
> > nice site, thanks.  I looked at the lego library posted here, recently, but
> > found that to be in .. a not-useful state.  the one from the Dutch site is much
> > better, even has documentation!
> >
> I started with the links to the older version of the library posted by Melody;
> Subject: LEGO Library Date: 10 Nov 2019 21:15:01
> This older library is for Version 3.1 but contains 4/5 example LEGO models. Out
> Of Date - but looked very interesting so I disappeared down the LEGO rabbit
> hole. I could be here for some time ....
>
> The new version at the Dutch site is Version 3.7, has changed partnames and
> colours, and includes radiosity, for example. Also it contains 4/5 different
> examples. E.G. 04551_Crocodile_Engine.   'povray crocodile_engine' invokes the
> 'crocodile_engine.ini' just fine, output is tga. (Note: edit the pov file to
> switch off radiosity or lose the will to live).

right.  the "new" version is all I have here.

had to change definition and use of 'grey' in 'material.lib' to 'grey1' to avoid
the keyword name clash, but works ok from then.  the formatting of some files
too is weird -- all content in a single line!

you're not wrong on radiosity.  have now set 'quality=8' in the 'povray.ini'.
:-)


> Switch to one of the earlier examples (6338_hurricane_harbour) and that's when I
> hit the Command Line problem on 3.8: The 6338.ini/6338.pov files cant be called
> successfully unless it's 'povray +I6338.pov', which ignores the .ini file
> anyway.

so, the new version only has 4551, 6482, and 6923 samples.  the Dutch site says
'6338' source "not yet available".

> ...
> My point is that the Command Line call is failing to behave as expected.

if you still have unmodified copies of 6338, would you mind posting?  I do want
to have a look (next week).


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
> if you still have unmodified copies of 6338, would you mind posting?  I do want
> to have a look (next week).
>

Best 'unmodified copies' are at Melody's 2nd posting with the
attachment"more_lego.zip" ... see:

http://news.povray.org/povray.binaries.utilities/thread/%3Cweb.5dc87d5f9ec945b49da690110%40news.povray.org%3E/

got to dash - UK election news starts in 5 mins - will be up all night!
tery

Post a reply to this message

hi,

"greytery" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > if you still have unmodified copies of 6338, would you mind posting?  I do want
> > to have a look (next week).

ok, had a quick first look at 6338.  problems with (a) renamed components (eg
"ffblock2_2" is now "tile2x2".  there are quite a few others) in 6338.{mac,pov},
and  (b) names of materials (eg there's no "red_tex" but a "bright_red_tex"
exists); also, one or two instances where macro #arguments do not match up.
</sigh>  will have a closer look in the coming week.

> got to dash - UK election news starts in 5 mins - will be up all night!

was it .. worth it?  ;-)


regards, jr.

Post a reply to this message

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

OK OK OK. 'FIXED'. Stand Down. As you were ...

The problem is with the .ini files in each of the OLD examples, e.g. 6338.ini.
These were generated by Version 3.1.  I've 'fixed' that by copying one of the
NEW ini, e.g. crocodile_engine.ini, and replacing the OLD .ini file - changing
the 'Input_File_Name=' of course.  Once done they ALL behave themselves as
normal. Just what the real underlying problem is - not sure - probably low level
file format handling, unix/windows, blah, blah. Whatever.
They are now producing some smashing .tga scenes and much fun will follow.

> ok, had a quick first look at 6338.  problems with (a) renamed components (eg
> "ffblock2_2" is now "tile2x2".  there are quite a few others) in 6338.{mac,pov},
> and  (b) names of materials (eg there's no "red_tex" but a "bright_red_tex"
> exists); also, one or two instances where macro #arguments do not match up.
> </sigh>  will have a closer look in the coming week.
>

Yep. I 'fixed' the renaming issue for these OLD models with a "renamed.mac"
file, which contains about 120 lines like :
    #macro f_block1_12(color_tex,age) plate1x12(color_tex,age) #end
Then in each of the OLD .pov files, #include "renamed.mac", and it flies.
The color issues - at the moment I've edited the NEW material.lib to contain the
OLD colors / textures, but it would be better to include the missing colors in
the "renamed.mac" file.
Another problem is with material_map. I found I had to remove 'interpolate 4'
from these OLD macros, otherwise the transfers are smudged.
If you want I can post that .mac file here, but I think we should get Anton
involved because the files all have his Copyright.

> > got to dash - UK election news starts in 5 mins - will be up all night!
> was it .. worth it?  ;-)

Don't like watching grown men cry.  But it takes all the satisfaction out of
Voting if you have to hold your nose and keep your eyes shut when you put your
cross in the box.

tery

Post a reply to this message

hi,

"greytery" <gre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> Yep. I 'fixed' the renaming issue for these OLD models with a "renamed.mac"
> file, which contains about 120 lines like :
>     #macro f_block1_12(color_tex,age) plate1x12(color_tex,age) #end
> Then in each of the OLD .pov files, #include "renamed.mac", and it flies.

neat.


> The color issues - at the moment I've edited the NEW material.lib to contain the
> OLD colors / textures, but it would be better to include the missing colors in
> the "renamed.mac" file.
> Another problem is with material_map. I found I had to remove 'interpolate 4'
> from these OLD macros, otherwise the transfers are smudged.

thanks for info.


> If you want I can post that .mac file here, but I think we should get Anton
> involved because the files all have his Copyright.

good idea.  I've not seen an email address in the files yet, so, if you have it,
perhaps he can be persuaded to join in, here?


> > > got to dash - UK election news starts in 5 mins - will be up all night!
> > was it .. worth it?  ;-)
>
> Don't like watching grown men cry.  But it takes all the satisfaction out of
> Voting if you have to hold your nose and keep your eyes shut when you put your
> cross in the box.

like DB, I was surprised by the scale, 365 seats!  (incredible..)  alas, that
post appears to have .. disappeared.


regards, jr.

Post a reply to this message