I go ahead and make those changes?
>>
>
> I would say yes. See if it works without any unexpected quirks. Then I
> would say the PR will be ready for review.
>
> On Wed, Oct 16, 2024 at 11:14 AM Knee Snap wrote:
>
>> I've got no objections on refactoring the validate
{
"emoji": "👍",
"version": 1
}
only and deprecate the
> constructor. My suggestion is to keep it as is (for now), and add a color
> array. Determine if colors are used by a length == 0 check. The vertex
> format has no impact on this.
>
> On Tue, Oct 1, 2024 at 2:01 AM Knee Snap wrote:
>
>> The code snippe
vertex, just for its positional
> components that are mandatory (at the very least, points should be
> supplied).
>
> On Mon, Sep 30, 2024 at 3:12 AM Knee Snap wrote:
>
>> These are some great points!
>>
>> Nir mentioned a builder-style pattern for TriangleMesh,
These are some great points!
Nir mentioned a builder-style pattern for TriangleMesh, but I struggle to
think of how this could work well, as one critical feature of the current
API is to be able to dynamically update mesh data, which is very important
for any kind of animated mesh. I'd love to see
ature (and vertex colors
> is even more niche), which is probably why the response to your
> proposal is a bit slow. That being said, I'll take a closer look at
> your proposal during the weekend.
>
>
>
> On Fri, Sep 13, 2024 at 4:59 AM Knee Snap wrote:
> >
> >
r look during the weekend. There are a lot of
>> issues in my queue that I can't find the time to get to. Also be patient
>> with the replies, it takes time to get to an issue because there are many
>> ideas/drafts and not a lot of people.
>>
>> The #1281 PR was
s for me taking over your PR? I don't have access
to the original RFR email thread or feature proposal as I only recently
joined the mailing list.
Thanks!
On Fri, Sep 6, 2024 at 4:32 PM Knee Snap wrote:
> Hi all, while waiting on Kevin to review the feature proposal (if I
> understand
ce we seem to have no further design discussion points we're okay
to talk about implementation?
Draft PR: https://github.com/openjdk/jfx/pull/1557
On Thu, Sep 5, 2024 at 9:08 PM Knee Snap wrote:
> Thanks everyone who has commented and given feedback.
>
> With no further discussio
, 2024, 12:24 PM Knee Snap wrote:
> I don't know what gamma refers to in the context of vertex colors, sorry.
>
> It's not using the gamma color space if that's the question (but neither
> is the rest of JavaFX 3D).
>
> If gamma is meant as opacity, then setting t
, 2024, 7:44 AM Andy Goryachev
wrote:
> I am not a 3D expert; one question: how is the gamma value set for color
> interpolation?
>
>
>
> Thanks!
>
> -andy
>
>
>
> *From: *openjfx-dev on behalf of Knee Snap
>
> *Date: *Tuesday, September 3, 2024 at 23:
t;
> As for your specific proposal, im all for it and i think it should be
> implemented because every engine/graphics API that is at least half decent
> supports vertex colors and i believe it is an important feature.
>
> On Wed, Sep 4, 2024 at 7:53 AM Knee Snap wrote:
>
>>
Hello all,
This is a continuation of a previous email thread: "[Feature Proposal]
Vertex Colors on TriangleMesh".
I'm creating a new email thread because after discussion I've put together
a feature proposal, and it serves largely as a summary of the previous
email thread. (Better organized as a f
By following Kevin's suggestion, I was able to successfully build JavaFX
and run the unit tests.
Thanks Kevin!
On Fri, Aug 30, 2024 at 12:51 PM Knee Snap wrote:
> I tried this suggestion (the one Kevin has suggested) but I got warnings
> about Gradle verification failures, an
:media:buildWINGlib"
> (which is where the error is occurring) with --debug or --info.
>
> Did you set up Visual Studio? It's required
> for WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
>
> - Nir
>
> On Fri, Aug 30, 2024 at 8:23 AM Knee Snap wrote:
>
>> Upon trying
Upon trying to run "./gradlew -PFULL_TEST=true -PUSE_ROBOT=true
-PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true all test", I am eventually
confronted with the following output:
"
> Task :media:buildWinGlib
make: Entering directory
'/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstream
of this is by way of saying that even if this feature proceeds, it
> won't happen quickly.
>
> -- Kevin
>
> [0] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> [1]
> https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#new-features--api-additions
> [2]
Hoping for further feedback from Michael and others on this feature
proposal, as I'm hoping to work on a draft PR soon.
Thanks!
On Fri, Aug 23, 2024 at 2:03 PM Knee Snap wrote:
> Thanks for the clarification on how the design would work.
>
> However, this design is separate/un
s. Most likely, this API is
> deficient in many ways, so take it as a discussion point rather than a
> serious API proposal.
>
>
>
> On Fri, Aug 23, 2024 at 6:49 AM Knee Snap wrote:
> >
> > Gottcha,
> >
> > That helps give the context I need to better
s), then why wouldn't we
> be able to connect this to our existing shaders?
>
> Again, I'm not saying that this is a good idea; it might not work for
> any number of reasons. But I think these alternative approaches should
> at least be explored a little bit befo
tion is
still a worthwhile feature to add on its own which does not conflict with
the future user-shader support.
On Thu, Aug 22, 2024, 7:44 PM Knee Snap wrote:
> Was hoping to get feedback on my suggestion instead, but another
> suggestion doesn't work.
>
> The idea of a CustomMesh
Was hoping to get feedback on my suggestion instead, but another suggestion
doesn't work.
The idea of a CustomMesh is impossible to implement until after we
have fully user-supplied shader support, which I've already addressed as
being not the scope of this change (but instead it is a separate fut
Hi all, just sending an update on the proposal since I'm hoping to start
work on a draft PR for this, but I'd like feedback on the proposed API
(with & without the changes mentioned in the previous email).
Thanks!
On Tue, Aug 20, 2024 at 11:49 PM Knee Snap wrote:
> Hi Michae
Hi Michael,
Thanks for the response!
*> Have you thought about ways how we could allow deverlopers to define
custom formats? Maybe that would also require a new kind of Mesh that can
accept custom data.*
Yep, and while I'd very much like this eventually, this cannot occur before
user-supplied sha
t POINT_NORMAL_TEXCOORD_COLOR
+ int getColorElementSize()
+ int getColorIndexOffset()
Any thoughts on this? My next goal is to create a draft PR with this
implemented, but I'm still looking for feedback.
On Tue, Aug 20, 2024 at 8:41 PM Knee Snap wrote:
> Thanks for the reply!
>
>
re this feature isn't used. Seeing as this is only vertex shader
> data, which tends to be cheap and the number of registers available for it
> large, I don't foresee problems off the top of my head.
>
> Implementing this will require simultaneous implementations for D3D9 and
&g
This is my first time attempting to submit a feature request so bear with
me if I mess up the instructions, I'll do my best to rectify any issues if
they occur and are pointed out.
*Feature Proposal:* Vertex Colors on TriangleMesh
Add a new ObservableIntegerArray to TriangleMesh which contains ver
27 matches
Mail list logo