My preference would be to add support only for Linear and Nearest in any
case.
-- Kevin
On 6/21/2023 4:48 AM, Matija Brown wrote:
As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR
filters are available.
There might be a way of getting around it by implementing some own
algorithm for OpenGL and Metal but that seem slightly
over the top. So either one would have to keep the options limited to
the two supported everywhere
or go with the “conditional” features.
Having had a look at DirectX the APIs seem not to differ too much.
If I remember correctly, in OpenGL you parse the texture filter when
the texture is being created, while in DirectX as it is bound
to the sampler (it is a sampler state after all) it would have to be
set before every render call. However it shouldn’t make any
API difference really, as we can just have a field somewhere and the
parse it along when needed.
Cheers,
Matija.
*From: *Jayathirth Rao Daarapuram Venkatesh Murthy
<mailto:jayathirth....@oracle.com>
*Sent: *Wednesday, 21 June 2023 13:09
*To: *Nir Lisker <mailto:nlis...@gmail.com>; Matija Brown
<mailto:matija.br...@outlook.de>
*Cc: *openjfx-dev@openjdk.org
*Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture
Nearest-Sampling on PhongMaterial
In OpenGL we set GL_LINEAR by default at :
https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221
And Metal supports only two types of Min/Max filters :
Nearest(default) and Linear. So even if D3D supports multiple types we
might be limited to support only these 2 filters for all platforms.
Thanks,
Jay
*From: *openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Nir
Lisker <nlis...@gmail.com>
*Date: *Wednesday, 21 June 2023 at 3:57 PM
*To: *Matija Brown <matija.br...@outlook.de>
*Cc: *openjfx-dev@openjdk.org <openjfx-dev@openjdk.org>
*Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture
Nearest-Sampling on PhongMaterial
First of all, please excuse directly e-mailing you earlier today.
Working with mailing lists is quite new for me and apparently I
forgot to add
the mailing list to cc.
I didn't get any private email, so you seem to be doing better than
you thought with the mailing list :)
With the OpenGL-side I do have some experience. Concerning the
D3D-side of things it would probably mean convincing
Somebody that it is a good idea to finally apply the suggested change.
There would be some API change required of course. As a basic
concept it would probably be sensible to add this as a parameter
to the PhonMaterial-class.
Alternatively it might make sense to add a “Texture” class that is
used a a DiffuseMap in the PhonMaterial. But that seems slightly
overkill.
Where to put the new methods in the Java side is not the
concerning part, it's how to create methods that match all
the pipelines. In D3D, the method for setting the filter is detailed
in [1], and its possible parameters in [2][3][4]. So suppose that I'm
looking at the list of available filter types there:
D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC,
D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO,
if OpenGL supports a somewhat different set of filters, we will have
some clashes in the Java API side.
Generally, we would like to give as much flexibility to the user as
possible, but need to be careful with platform-specific functionality.
We could round *some* corners. For example, I think that if we have an
enum for the filter types above that is a union of the ones available
in the different pipelines, and if a few are supported by only one of
the pipelines, we could note it in the docs and get away with it
(something similar to a conditional feature). However, if the whole
native pipeline setup for texture filtering is different, which means
a different set of Java API methods per pipeline, then that's too much.
All this means is that to continue we need to figure out what the API
for each pipeline looks like, what's the most functionality we can
have for each pipeline, and then how we can unite them into a single
Java API with the hopes of being able to reconcile the differences
"well enough" (whatever that will mean).
[1]
https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate
[2]
https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype
[3]
https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype
[4]
https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0
On Wed, Jun 21, 2023 at 12:45 PM Matija Brown
<matija.br...@outlook.de> wrote:
First of all, please excuse directly e-mailing you earlier today.
Working with mailing lists is quite new for me and apparently I
forgot to add
the mailing list to cc.
With the OpenGL-side I do have some experience. Concerning the
D3D-side of things it would probably mean convincing
Somebody that it is a good idea to finally apply the suggested change.
There would be some API change required of course. As a basic
concept it would probably be sensible to add this as a parameter
to the PhonMaterial-class.
Alternatively it might make sense to add a “Texture” class that is
used a a DiffuseMap in the PhonMaterial. But that seems slightly
overkill.
As I am not very well acquainted with current design principles of
this library, these things should lie in more experience
contributors hands.
*From: *Nir Lisker <mailto:nlis...@gmail.com>
*Sent: *Tuesday, 20 June 2023 20:50
*To: *Matija Brown <mailto:matija.br...@outlook.de>
*Cc: *openjfx-dev@openjdk.org
*Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture
Nearest-Sampling on PhongMaterial
Which leads to the question; Does there, in JavaFX exist
something comparable to setting the texture-sampler to NEAREST
instead of LINEAR sampling?
There is no API to set the texture filter. If you would like to
contribute and add it, I can help. It needs to be compatible with
both Direct3D and OpenGL (not sure how the work on Metal is
going), so this can be a challenge.
For the D3D side, see this issue in JBS [1]. The relevant code is
at [2]. I didn't look at the OpenGL side.
- Nir
[1] https://bugs.openjdk.org/browse/JDK-8092272
[2]
https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621
On Mon, Jun 19, 2023 at 10:15 PM Matija Brown
<matija.br...@outlook.de> wrote:
On my never ending journey of building a Minecraft-clone in
every graphics-framework available,
I have come across JavaFX for the next attempt.
However a minor inconvenience has crossed my path in the process:
Using the (very well developed!) 2D-Graphics displaying
pixel-art style images is no trouble whatsoever.
Simply rendering it to a canvas and disabling smoothing does
the job just fine. Unfortunately, I have been
unable to figure out how to achieve a similar thing using the
3D-Graphics engine and the PhongMaterial that comes with it.
Which leads to the question; Does there, in JavaFX exist
something comparable to setting the texture-sampler to NEAREST
instead of LINEAR sampling?
Unfortunately the latest information I could find online was
from about 2013 and much has (probably)
changed since then. Thus the question is being posed once again.
I whish to excuse myself for probably repeating a fairly
common question,
Kind regards,
Matija Brown.
