[API Review] FX 8 3D API

[Joe Andresen]

see response inline.

----- Original Message -----
From: kevin.rushforth at oracle.com
To: joseph.andresen at oracle.com
Cc: openjfx-dev at openjdk.java.net
Sent: Thursday, February 7, 2013 3:53:59 PM GMT -08:00 US/Canada Pacific
Subject: Re: [API Review] FX 8 3D API

Even if we wanted to do this, it could not be accomplished by making 
Paint a subclass of Material without an incompatible API change.

I didn't say to make paint a subclass of material....

 All 
that you would gain by making Paint a subclass of Material is the 
ability to render a 3D shape with a gradient or a solid color, which 
seems not all that useful.

That is what a texture map is for, i think it could be useful.


What you are talking about below would only be possible if you made 
Material a subclass of Paint, but there isn't enough value in doing that 
to justify changing all of the 2D shaders to allow this (not to mention 
just defining what the semantics of this would be).

actually... this isnt so incompatible with prism now... we would simply replace our paint pixel shaders with material ones. multiplying the color generated by the material shader with the mask would give desired results... i think.... 

> The current way does not limit us from doing this in the future so 
> that is why it is just a thought :) .

Right. For FX 8 they will be separate classes with no common superclass. 
We could extend this later if desired (not convinced, though).

indeed.

-- Kevin


joe andresen wrote:
>
> Just a thought,
>
> I would think that Color, ImagePattern, and the Gradients could be 
> instances of Materials.
>
> A Material is a texture that is applied to a surface. In todays 
> graphics pipeline, the texture on the surface is calculated with 
> shaders, float3 color variables, and any other types of variables the 
> shaders might use.
>
> If you were to to extend this methodology to prism, setting the fill 
> of a Shape with a material would give a more detailed interface for 
> what will be processed on those pixels.
>
> For Example, if Color was a Material it would look something like:
>
> //pseudo code
>
> Material color_Material;
> //any other initialize code
> color.setPixelShader(color_Shader);
> color.setFloat3(red_Color);
>
> Rectangle rect = new Rectangle();
> rect.setFill(color_Material);
>
> Now this totally breaks down with prism's shape rendering 
> implementation, but from an API standpoint, this makes sense to me. 
> (the problem being that in prism, what 2d shape you are rendering is 
> determined by a pixel shader.)
>
> Here are a couple of other somewhat random libraries' abstraction of a 
> Material.
>
> http://clb.demon.fi/gfxapi/docs/Material_summary.php
>
> http://docs.unity3d.com/Documentation/ScriptReference/Material.html
>
> Interesting how Unity has specific variables that are meant for a Main 
> Color. I think this has to do with their public and not standard 
> shader architecture. (Surface Shaders)
>
> Flash 3d has no such thing, where instead you have to set shader 
> variables from a context, which in my opinion is nasty.
>
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display3D/Context3D.html 
>
>
> -Joe
>
> The current way does not limit us from doing this in the future so 
> that is why it is just a thought :) .
>