<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics">
    <title>gmane.comp.graphics.opengraphics</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9526"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9525"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9524"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9523"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9522"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9521"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9520"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9519"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9518"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9517"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9516"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9515"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9514"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9512"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9510"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9509"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9508"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9507"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9506"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9505"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9526">
    <title>Re: [Kinda OT] Perhaps novice question about painting3D scenes with alpha blending</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9526</link>
    <description>&lt;pre&gt;I found a solution to my problem:

        universe.getViewer().getView().setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);

Now everything looks right.

I'm starting to think that Java3D isn't half bad.  :)
&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2012-01-18T18:29:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9525">
    <title>Re: [Kinda OT] Perhaps novice question about painting3D scenes with alpha blending</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9525</link>
    <description>&lt;pre&gt;This sounds almost like the 4 steps of coming to terms with a terminal 
disease.
&lt;/pre&gt;</description>
    <dc:creator>Matt</dc:creator>
    <dc:date>2012-01-18T07:51:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9524">
    <title>Re: [Kinda OT] Perhaps novice question about painting3D scenes with alpha blending</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9524</link>
    <description>&lt;pre&gt;
Alpha blending in complex scenes is just horrible. It's not the
fault of Java3D, Direct3D and OpenGL can't do any better.

Basic problem is that compositing ops aren't commutative. Added
problem is that there's no 'transparency' in the depth buffer.

For intra-object transparency, for instance the cockpit of a
plane / interior of a car, most scene graphs have an ordering
node which says 'draw this bit after that bit.' End result is
the solid interior always being drawn before the transparent
bits around it. Because of the depth buffer the exterior can
still block other objects it shouldn't, but the viewer is mostly
going to notice that they can see 'inside' the cockpit/car and
that's good enough.

For simple inter-object transparency, usual way is to draw all
the opaque objects/parts of objects first with depth writes
enabled. Then draw all the transparent parts, with depth tests
but not writes. If transparent polys overlap other transparent
polys, they have to be drawn back to front. (Which on modern
GPUs &lt;/pre&gt;</description>
    <dc:creator>Hugh Fisher</dc:creator>
    <dc:date>2012-01-18T03:21:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9523">
    <title>[Kinda OT] Perhaps novice question about painting 3D scenes with alpha blending</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9523</link>
    <description>&lt;pre&gt;I know graphics architecture, and I know how to do all the math.  But,
oddly, I've never actually used a 3D API like OpenGL, Direct3D or
Java3D.  Well, I'm trying to write a demo for a paper I'm presenting
at HPCA, and I've run into something odd.  I was hoping some with
actual front-end experience might be able to help me.  I figured since
this is a graphics mailing list, this wouldn't be horribly off topic.

I'm using Java3D to render a scene with lots of translucent planes.
If I make everything opaque, it's fine, because it's doing Z culling.
But I'm finding that the rendering order isn't near-to-far, as I
expected, but something perhaps related to the order in which I
created the scene elements.  As a result, when I turn on alpha
blending, it looks horrible.

I'm starting to worry that what I'm going to have to do is do all my
coordinate transforms up-front (rather than create a transform group
and transform the group), then sort by Z order, then add them to the
scene (and by trial and error determine wh&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2012-01-18T02:31:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9522">
    <title>Re: To offer "&lt; at &gt;opengraphics.org"emailaddressforwarding</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9522</link>
    <description>&lt;pre&gt;If you have a good spam filter, then make a web page with all the 
addresses at opengraphics with a little note who is behind it - name + 
responsibilities or contribution. Anyone who wants such a premium 
address should be not afraid being in a "phonebook".

But from the viewpoint of OSS, where people are rather individualist, 
the niceness of these email addresses are not even worth of asking for 
one :) So keep them for the ones who are willing to promote or run the 
opengraphics project in the future (for communication with distributors 
and fabs it is a benefit to have an in-business contact).

Daniel


On 11/23/2011 06:50 PM, Matt wrote:
&lt;/pre&gt;</description>
    <dc:creator>Ing. Daniel Rozsnyó</dc:creator>
    <dc:date>2011-11-23T18:22:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9521">
    <title>Re: To offer "&lt; at &gt;opengraphics.org" emailaddressforwarding</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9521</link>
    <description>&lt;pre&gt;Personally I haven't contributed much to the effort; I have been just a 
lurker.
I think the addresses should be limited to those who have contributed in 
some way; that rules me out!

Matt
&lt;/pre&gt;</description>
    <dc:creator>Matt</dc:creator>
    <dc:date>2011-11-23T17:50:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9520">
    <title>To offer "&lt; at &gt;opengraphics.org" email addressforwarding</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9520</link>
    <description>&lt;pre&gt;Now that opengraphics.org has been transferred to Yann, we'd like to
offer "&amp;lt; at &amp;gt;opengraphics.org" email addresses.  For now, just forwarding.

Should we make this open to just anyone?

Or should we take nominations for people who have been long-time
contributors, so that there's some specialness or exclusivity to it?
:)

&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-11-23T16:56:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9519">
    <title>Re: Re: opengraphics.org domain going to expire</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9519</link>
    <description>&lt;pre&gt;Thanks everyone.  I'm going to pay the bill first.  After I do that,
what do I need to do to transfer the domain?
&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-11-17T01:09:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9518">
    <title>Re: Re: opengraphics.org domain going to expire</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9518</link>
    <description>&lt;pre&gt;If all we really owe is $35, then I'll just call and pay it now and
tell them that we want to transfer opengraphics.org to another owner.

Should we keep the traversaltech.com domain for any reason?  (I really
liked the name. :)  )


On Wed, Nov 16, 2011 at 4:06 PM, Matt &amp;lt;matt&amp;lt; at &amp;gt;mattkeenan.net&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-11-16T21:09:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9517">
    <title>What's going on with OGP? Here's something...</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9517</link>
    <description>&lt;pre&gt;With my Ph.D. and family taking up most of my time right now, I
haven't gotten to work on OGP much.  But I haven't forgotten about it.

For my consulting work, I had to learn Java to write a cross-platform
app.  Separately, just as a way to further develop my skill, I wrote
this unrelated program:  https://sourceforge.net/projects/minuteman/

That's gotten me set up to work on what I REALLY wanted to do, which
is an IDE for chip design.  I mentioned this a long time ago.  One of
the problems with coding HDLs is the massive amount of error-prone
coding you have to do just to stitch modules together.  Get one wire
the wrong size, and you get misbehavior that causes to develop more
gray hairs.  If this could be done graphically, we could save a lot of
time and pain.  There are also lots of "standard" modules that can be
just pasted in and hooked up (fifes and various types of pipeline
stage templates come to mind).

I don't get much time to work on it, so I haven't gotten very far.
But here's a screenshot:
http&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-11-16T21:02:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9516">
    <title>Re: opengraphics.org domain going to expire</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9516</link>
    <description>&lt;pre&gt;Several people have offered to take over opengraphics.org, which we
appreciate very much.  We have a few things we have to resolve.

So, here's our situation.  Since Traversal no longer exists (we moved
the commercial rights over to Dapem, André's open source hardware
venture), we miscommunicated with our ISP (Dreamhost), and ended up
not canceling the account and also not paying the bill.  As a result,
we owe them $35.  As well as traversaltech.com, we also registered the
opengraphics.org domain through the same account.  In order to renew
the domain, we'd have to pay the $35 for hosting Traversal, which we
don't care about anymore.  It appears that if we just don't pay, the
domain will expire on Dec 1.  However we don't know if Dreamhost will
hold it hostage after that point or not.  $35 isn't much at all, so if
that's necessary to get it released, I will pay it, but only if
necessary.  Perhaps some people can shed some insight into this.

As for who gets opengraphics.org, that's up to you guys... whoever&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-11-16T20:45:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9515">
    <title>opengraphics.org domain going to expire</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9515</link>
    <description>&lt;pre&gt;We're having some problem with our registrar, and the opengraphics.org
domain is going to expire.  Would anyone be willing to re-register the
domain with another registrar after that?

&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-11-16T05:51:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9514">
    <title>Re: Economics of open hardware</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9514</link>
    <description>&lt;pre&gt;
The issue as far as software is concerned is not so much about money as 
it is freedom.
Richard Stallman has explored these issues convincingly and that is why 
I support
the Free Software Foundation.

I think, long run, that free software will win. In many areas it is 
already superior.
Also it is more trustworthy since it is peer-reviewed, auditable, and 
has a better tool-chain.
You can build on it.

Citizens should insist upon free software for voting machines for example.
An ethical question: If the marginal cost of software approaches zero, why
shouldn't everyone have it ?

Hardware also should have some attributes that can make it more trustworthy.
An open-source BIOS is good and a blob-free release of GNU/Linux like 
GNUSense
is more free. The Tor application on a Freedom-Box can give us better 
security.
I look for combinations of these, recognizing that cutting-edge features 
are slow
to arrive. That's the kind of hardware that I would like to buy.

I did buy one of these: http://www.osnews.com/st&lt;/pre&gt;</description>
    <dc:creator>Robert Vogel</dc:creator>
    <dc:date>2011-10-28T15:27:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9512">
    <title>Need help maintaining wiki</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9512</link>
    <description>&lt;pre&gt;We need a new wiki maintainer/editor.  Would someone be willing to do
some minor edits and spam removal while we're in a holding pattern?

I'll have my Ph.D. done early next year, and Andre should have his
project going sooner or later.  So it'll pick up again.  I've also
been doing some circuit design on the side here and there.  So OGP
isn't dead, but prominent members have been pulled in too many
directions for the time being.


Thanks.


&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-10-03T16:36:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9510">
    <title>Re: Importance of denormalized floats?</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9510</link>
    <description>&lt;pre&gt;

On 27/08/11, Timothy Normand Miller   wrote:

I think that introducing GPGPU into this project is a nasty case
of feature creep and that drastic measures are needed: namely
forgetting about it entirely. Just build a frickin' graphics card
and ship it for now.


There are IMHO a lot more people in the FOSS world who are
interested in high performance games/graphics/design/ than in
GPGPU. Adding denormalised floats, double precision, etc
is a lot of additional complexity for the benefit of very few.


--
        Hugh Fisher

&lt;/pre&gt;</description>
    <dc:creator>Hugh Fisher</dc:creator>
    <dc:date>2011-08-27T00:49:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9509">
    <title>Re: Importance of denormalized floats?</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9509</link>
    <description>&lt;pre&gt;I remember that.  I was also in favor of the same argument.  I was
mostly asking about GPGPU.  Anyhow, I'll simply accept your reargument
for the general case and move on.  :)

On Thu, Aug 25, 2011 at 10:19 PM, Hugh Fisher &amp;lt;hugh.fisher&amp;lt; at &amp;gt;anu.edu.au&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-08-26T14:02:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9508">
    <title>Re: Re: Importance of denormalized floats?</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9508</link>
    <description>&lt;pre&gt;Usually, except when the number is so small that it can't be
normalized with the smallest possible exponent.

On Thu, Aug 25, 2011 at 10:33 PM, Dieter BSD &amp;lt;dieterbsd&amp;lt; at &amp;gt;engineer.com&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-08-26T14:01:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9507">
    <title>Re: Importance of denormalized floats?</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9507</link>
    <description>&lt;pre&gt;
Maybe it has been too long since I took that architecture class,
but aren't you supposed to keep floats normalized?
&lt;/pre&gt;</description>
    <dc:creator>Dieter BSD</dc:creator>
    <dc:date>2011-08-26T02:33:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9506">
    <title>Re: Importance of denormalized floats?</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9506</link>
    <description>&lt;pre&gt;
I think this came up once before and I'm going to give the same
answer as before because nothing has changed.

For graphics, denormalized floats are not at all important. Any
really small number rounds to zero. Any really large number
is infinity. No exceptions, no special handling. Forget about
being IEEE compliant: graphics programmers don't want it. Heck,
we don't really care about double precision.

Just build something that does graphics. GPGPU can be added later.

&lt;/pre&gt;</description>
    <dc:creator>Hugh Fisher</dc:creator>
    <dc:date>2011-08-26T02:19:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9505">
    <title>Importance of denormalized floats?</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9505</link>
    <description>&lt;pre&gt;How important are denormalized floats in GPUs?  For graphics, I would
expect very little.  For GPGPU, it might matter.

The reason I ask pertains to floating point multiplies.  If you want
to multiply by denormalized numbers, then the number of bits you have
to process may be more.

Let's think about what kinds of results you can get from a multiply
and how this applies to shifting.

  If you multiply any two denormalized numbers, you'll get an
underflow simply because of the exponent.
  If you multiply any two normalized numbers, then the smallest result
(ignoring the exponent) is 1.0, requiring no shift or adjustment to
the exponent.  The largest result you can get is 3.999..., which
requires the exponent (the sum of the operand exponents) to be
increased by 1 and the mantissa to be shifted right by 1.  (But to be
clear, since these are 24-bit numbers, their product is 47 bits, and
you have to discard the lower 23 bits (with rounding) to get back to
24.  Then you may shift some more.)
  If you multiply a n&lt;/pre&gt;</description>
    <dc:creator>Timothy Normand Miller</dc:creator>
    <dc:date>2011-08-25T19:55:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9504">
    <title>Re: Fwd: [LLVMdev] Xilinx zynq-7000 (7030) as aGallium3D LLVM FPGA target</title>
    <link>http://permalink.gmane.org/gmane.comp.graphics.opengraphics/9504</link>
    <description>&lt;pre&gt;https://secure.wikimedia.org/wikipedia/en/wiki/DEC_Alpha
https://secure.wikimedia.org/wikipedia/en/wiki/Alpha_21064

The very first Alpha (EV4) have a fpu,i don't see your point.

I imagine that you can make opengl with integer ALU only but a 32 bits
integer multiplication unit is about the same size than a 32 bits
floating point multiplication unit. And this is size could be bigger
than the rest of the cpu.

2011/8/22 Luke Kenneth Casson Leighton &amp;lt;luke.leighton&amp;lt; at &amp;gt;gmail.com&amp;gt;:
&lt;/pre&gt;</description>
    <dc:creator>Nicolas Boulay</dc:creator>
    <dc:date>2011-08-22T11:56:27</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.graphics.opengraphics">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.graphics.opengraphics</link>
  </textinput>
</rdf:RDF>

