 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 11 Aug 2020 13:19:23 -0400, Bald Eagle wrote:
> Jim Henderson <nos### [at] nospam com> wrote:
>
>> > I don't entirely disagree, but PDF is not an open format, so from a
>> > "free software" perspective, would be strongly discouraged IIRC.
>> > Providing it in a format that could be published in multiple formats,
>> > OTOH, would be a really good solution.
>>
>> ePub would probably be a better choice, since that standard is
>> completely open.
>
> https://extensions.libreoffice.org/en/extensions/show/writer2epub
>
> done.
Excellent :)
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11.08.2020 17:46, Jim Henderson wrote:
> I don't entirely disagree, but PDF is not an open format, so from a "free
> software" perspective, would be strongly discouraged IIRC. Providing it
> in a format that could be published in multiple formats, OTOH, would be a
> really good solution.
Actually, PDF is an ISO standard and even usable for archive purposes.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 11 Aug 2020 21:14:13 +0200, Thorsten wrote:
> On 11.08.2020 17:46, Jim Henderson wrote:
>> I don't entirely disagree, but PDF is not an open format, so from a
>> "free software" perspective, would be strongly discouraged IIRC.
>> Providing it in a format that could be published in multiple formats,
>> OTOH, would be a really good solution.
>
> Actually, PDF is an ISO standard and even usable for archive purposes.
Yeah, I know it can be used that way, but its history makes it somewhat
less suitable for some OSS projects and implementations. While we
wouldn't use signing or forms (for example), those implementations are
highly proprietary and only supported by Adobe.
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 11/08/2020 om 19:19 schreef Bald Eagle:
> https://extensions.libreoffice.org/en/extensions/show/writer2epub
>
> done.
>
Done too.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Lastly, and this is mostly here for completeness, would be articles that deal
> with what _can't_ be done - and why. This may help someone just starting a
> scene from unproductively pursuing a doomed strategy. It's also a good place to
> discuss what scene coders probably do best - fake it with a workaround that's
> good enough to fool the eye from the chosen perspective. Many people may be
> tempted to model the exact geometry of something, or a _whole_ something, when
> simply a close approximation and some clever texturing with normals will do the
> trick. Billboarding. Etc.
Great idea, only I hope it could be in an easy to evolve source like wiki for
instance, so that we could have the satisfaction of seeing stuff get crossed out
when new features and fixes get these issues resolved and workarounds
unnecessary.
> There should probably be a poll soliciting what actual users would like to see
> covered (and why), as well as a list of people they might like/hope to see
> invited articles by. (It's early and this is by no means an inclusive list)
> Paul Bourke, Inigo Quilez, Tor Olav Kristensen, Jaime Vives Piqueres, Paul
> Nylander, Robert McGregor, Ive, Norbert Kern, Gilles Tran, Christoph Hormann,
> Samuel Benge ... and others which I may not even be aware of.
Awesome and besides such obviously talented artists, In that list, space may be
also available to the talented persons who so often help new comers and even
advanced users to troubleshoot (thinking of all people like " Alain " (Martel?),
etc. ) to
give their most repeated or hard to find out pieces of advice.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
{bump}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/08/2020 10:17, Bald Eagle wrote:
> {bump}
Prod noted, thanks ;-)
I'll try to put together the steps needed for a release and post it this
week.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK so I'll start to address some of the things needed to be done to get
a good, solid 4.8 release. I'll spread this across several messages as I
get time.
(Before I begin: I have yet to fully catch up with this thread as there
are a number of messages I've left unread - I'll catch up later,
apologies if I duplicate/repeat something already covered).
One of the main issues we face (and where we could really do with
community help as this is hard to automate) is making sure all the
combined changes firstly don't outright break any of the shipped scenes
and snippets (by that I mean cause parse/render to fail with an error or
exception), and secondly don't cause any unexpected *visual* artifacts
(or at least not any unexpected ones that would fail the 'principle of
least astonishment' test that I ramble on about occasionally).
The first can be automated to a reasonable extent. The latter is really
part of the former (as to view the image you need to complete the
render) and is really, really difficult to automate. The reason for that
is it's a matter of perception; of a human's ability to look at
something and see it for what it is rather than a collection of pixels.
Computers are OK at looking a collections of pixels mathematically if
they have a base set of images (rendered e.g. by v3.7) to compare
against. They can see if a pixel is different by 0.001% and can even be
taught to understand things like gamma changes but it's much more
difficult to get an algorithm that correctly interprets what a *user*
would consider a 'right' or 'wrong' change from an image as a whole.
It really needs user input. If we could get a cadre of all the above-
mentioned images rendered with 3.7 (plus a selection of good external
candidates like HOF images and some newer works), then the same with
3.8, and have them all put up side-by-side on a website or some other
means of allowing multiple collaborators to view, rate and/or comment on
the differences then it would be a large step forward to getting 3.8 out
of the door.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> ...
> It really needs user input. If we could get a cadre of all the above-
> mentioned images rendered with 3.7 (plus a selection of good external
> candidates like HOF images and some newer works), then the same with
> 3.8, and have them all put up side-by-side on a website or some other
> means of allowing multiple collaborators to view, rate and/or comment on
> the differences then it would be a large step forward to getting 3.8 out
> of the door.
I have versions 3.7.0.8 and 3.8.0-alpha.10064268 installed on a machine, and
will be happy to render scenes with both and post the images. perhaps you could
start a new thread just for posting results? (until the "website or some other
means" becomes available)
there are around 400 scene files in v3.7; how to ensure that users do not
duplicate work? other than that, I can make a start tomorrow.
btw, regarding side-by-side, Linux users will have the (ImageMagick) 'montage'
utility which could be useful here. a command like:
$ montage v37img.png v38img.png -tile 1x2 -geometry +0+0 imgcmp.png
creates a single image with the v38 image below the v37; without internal
border(s).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 08 Sep 2020 04:55:43 +1000, Chris Cason wrote:
> It really needs user input. If we could get a cadre of all the above-
> mentioned images rendered with 3.7 (plus a selection of good external
> candidates like HOF images and some newer works), then the same with
> 3.8,
> and have them all put up side-by-side on a website or some other means
> of allowing multiple collaborators to view, rate and/or comment on the
> differences then it would be a large step forward to getting 3.8 out of
> the door.
Building on jr's suggestion, I wonder if the builds are happening with
some sort of CI/CD system, if it might be possible to automate the
montage and include a 'diff' image in it to show areas where the
algorithms differ. That might make it easier for someone looking at the
results to see what the differences are (and to look past areas that
might look different but are visually identical - because human eyes are
weird sometimes).
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
