Bitreverse and popcount functions were added. An overflow in the modulo
operator was fixed. An asymmetry in angle(transform t) was fixed so that
angle(yscale(-1))=0. Missing 3D underline characters were fixed.
The MSWindows binary is now 64-bit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear John,
while you attention as at Asymptote, I repeat my question about 3D export.
What route Asymptote will take
1) export pre-tessellated data (tringles, segments, dots) -
PRO: many possible formats, well-tested viewers, someties already built-in, ready editing tools for manual fine-tuning and combining
CONTRA: you used to be agains it, since tesselation you considered to be the task of the viewer
2) export beziers and NURBS
PRO: in theory the viewer can render better bitmap than from pre-tessllated data
CONS: given the current format, viewer and editor choice there are no ready tools for real-time viewing of NURBS with per-vertex color.
Using extensible formats like X3D or three.js scene tree some 3D viewers can be made to render NURBS, but that leads to viewer-dependancy, unconvertibility etc.
This approach has certain advantages over direct WebGL output, but from my point of view it is worse than pre-tessellated export.
Sincerely Michail
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Michail,
Since we now have our own in-house renderer, I plan to pursue both routes.
This will allow us to fix up many issues: transparency in OpenGL and PRC,
lack of a 3D vector PRC browser (Adobe reader does not remesh upon zooming,
so it is not a vector browser), discontinued support of PRC, no vertex
shading in PRC, 3D vector support for tablets (via WebGL), and, as you
mention, compatibility with existing tools. We have decided to develop a
new vector format called v3d. For pre-tessellated data we can use an
existing format.
Dear John,
while you attention as at Asymptote, I repeat my question about 3D export.
What route Asymptote will take
1) export pre-tessellated data (tringles, segments, dots) -
PRO: many possible formats, well-tested viewers, someties already
built-in, ready editing tools for manual fine-tuning and combining
CONTRA: you used to be agains it, since tesselation you considered to be
the task of the viewer
2) export beziers and NURBS
PRO: in theory the viewer can render better bitmap than from
pre-tessllated data
CONS: given the current format, viewer and editor choice there are no
ready tools for real-time viewing of NURBS with per-vertex color.
Using extensible formats like X3D or three.js scene tree some 3D viewers
can be made to render NURBS, but that leads to viewer-dependancy,
unconvertibility etc.
This approach has certain advantages over direct WebGL output, but from my
point of view it is worse than pre-tessellated export.
Since we now have our own in-house renderer, I plan to pursue both routes.
We have decided to develop a new vector format called v3d.
For pre-tessellated data we can use an existing format.
Where is that renderer? Is is realtime? C++ or JS?
Rendering NURBS to bitmap and tessllating to triangles look like different tasks.
Is it going to do both?
If you need a guinea pig for early tests - you can count on me. ;)
Michail
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, we only release 64 bit binaries, even now for Windows...Except that
the TeXLive builders have just now asked for a 32-bit Windows binary.
There aren't many 32-bit systems around any more and the Boehm GC garbage
collector works much much better on 64-bit systems,
where pointers are less likely to be confused with data.
And this is completely valid position.
But the question, however, is: why the archive is named asymptote-2.42.i386.tgz?
This is confusing. The user sees i386 in a name, downloads it,
and is surprised that asy is not working.
P.S. I've found this by chance, it's not that I need this 32bit file,
just want to point out that such inconsistency
can be a source of unnecessary frustration,
which can be easily avoided.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure, we can try to rename the file. Hopefully the name change won't cause
problems downstream...
We quietly made the transition in 2012 (version 2.16) and nobody noticed or
requested a name change until today.
It's still an i386-family architecture, just a 64-bit rather than a 32-bit
one.
And this is completely valid position.
But the question, however, is: why the archive is named
asymptote-2.42.i386.tgz?
This is confusing. The user sees i386 in a name, downloads it,
and is surprised that asy is not working.
P.S. I've found this by chance, it's not that I need this 32bit file,
just want to point out that such inconsistency
can be a source of unnecessary frustration,
which can be easily avoided.
Bitreverse and popcount functions were added. An overflow in the modulo
operator was fixed. An asymmetry in angle(transform t) was fixed so that
angle(yscale(-1))=0. Missing 3D underline characters were fixed.
The MSWindows binary is now 64-bit.
Dear John,
while you attention as at Asymptote, I repeat my question about 3D export.
What route Asymptote will take
1) export pre-tessellated data (tringles, segments, dots) -
PRO: many possible formats, well-tested viewers, someties already built-in, ready editing tools for manual fine-tuning and combining
CONTRA: you used to be agains it, since tesselation you considered to be the task of the viewer
2) export beziers and NURBS
PRO: in theory the viewer can render better bitmap than from pre-tessllated data
CONS: given the current format, viewer and editor choice there are no ready tools for real-time viewing of NURBS with per-vertex color.
Using extensible formats like X3D or three.js scene tree some 3D viewers can be made to render NURBS, but that leads to viewer-dependancy, unconvertibility etc.
This approach has certain advantages over direct WebGL output, but from my point of view it is worse than pre-tessellated export.
Sincerely Michail
Hi Michail,
Since we now have our own in-house renderer, I plan to pursue both routes.
This will allow us to fix up many issues: transparency in OpenGL and PRC,
lack of a 3D vector PRC browser (Adobe reader does not remesh upon zooming,
so it is not a vector browser), discontinued support of PRC, no vertex
shading in PRC, 3D vector support for tablets (via WebGL), and, as you
mention, compatibility with existing tools. We have decided to develop a
new vector format called v3d. For pre-tessellated data we can use an
existing format.
Regards,
-- John
On Tue, Apr 3, 2018 at 6:03 AM, Michail Vidiassov mvid@users.sourceforge.net wrote:
Dear John,
Where is that renderer? Is is realtime? C++ or JS?
Rendering NURBS to bitmap and tessllating to triangles look like different tasks.
Is it going to do both?
If you need a guinea pig for early tests - you can count on me. ;)
Michail
Is the executable found in asymptote-2.42.i386.tgz
supposed to be 64-bit?
Yes, we only release 64 bit binaries, even now for Windows...Except that
the TeXLive builders have just now asked for a 32-bit Windows binary.
There aren't many 32-bit systems around any more and the Boehm GC garbage
collector works much much better on 64-bit systems,
where pointers are less likely to be confused with data.
On Tue, Apr 3, 2018 at 5:57 PM, gk-v gk-v@users.sourceforge.net wrote:
And this is completely valid position.
But the question, however, is: why the archive is named asymptote-2.42.i386.tgz?
This is confusing. The user sees i386 in a name, downloads it,
and is surprised that asy is not working.
P.S. I've found this by chance, it's not that I need this 32bit file,
just want to point out that such inconsistency
can be a source of unnecessary frustration,
which can be easily avoided.
Sure, we can try to rename the file. Hopefully the name change won't cause
problems downstream...
We quietly made the transition in 2012 (version 2.16) and nobody noticed or
requested a name change until today.
It's still an i386-family architecture, just a 64-bit rather than a 32-bit
one.
On Tue, Apr 3, 2018 at 7:35 PM, gk-v gk-v@users.sourceforge.net wrote: