maybe I'm contrasting AAA vs indie development too much but, length is a core need for using vector

maybe I'm contrasting AAA vs indie development too much

but, length is a core need for using vectors correctly and efficiently

Kkhitiara where we have a loosely constrained type with few members and a bunch of extensi...

Perksey•10/21/23, 10:19 PM

this is the closing remark on which my brain has shut off here

Perksey•10/21/23, 10:19 PM

but these are all important discussion points, as it's bad to have a preconceived conlusion without considering all relevant factors

tannergoodingOP•10/21/23, 10:19 PM

as is normalization, if you aren't normalizing your vectors and local coordinate space
then you're likely losing precision and introducing physics and rendering bugs/quirks

tannergoodingOP•10/21/23, 10:20 PM

(and lots of rubber banding/jitter)

Ttannergooding because having a type where the user doesn't have access to 90% of the functiona...

Kai•10/21/23, 10:20 PM

Yeah I mean this I fully agree with. I'm just not sure separating into multiple types is the way I want out of this.
I like the 2.X idea of allowing anything on anything, but obviously "try it and see what happens" isn't great.
The current 3.0 design IMO goes too much into having too many things unavailable.
Having more types is of course a solution, but then we have to somehow get the user to choose the correct types.

tannergoodingOP•10/21/23, 10:21 PM

Another alternative is to force users to use floating-point (it's better/more appropriate anyways)
and provide some specialized functions for creating a

Vector2/3/4<T>

Vector2/3/4<T>

from integer types

khitiara•10/21/23, 10:21 PM

separate types would actually make my reflection-based vertex attribute stuff easyer tbh, it just feels awkward and the integer one doesnt have a natural name imo since point overlooks a bunch of uses for integer tuples supporting some basic vector ops

Ttannergooding maybe I'm contrasting AAA vs indie development too much but, length is a core n...

Kai•10/21/23, 10:21 PM

This is true IMO, but I like the rational for

Half

Half

a lot. If you choose the type you likely know of the trade offs and putting further barriers in place just to confirm you actually know what you're doing is unecessary. Similar for VectorN<byte> etc.

Kai•10/21/23, 10:22 PM

(also - ignoring any arguments around naming here, idk if I would feel good about Point either, given we also have line and other geometry but that's irrelevant right now)

Perksey•10/21/23, 10:23 PM

unless we explicitly decide on multiple types the name is irrelevant really

Ttannergooding Another alternative is to force users to use floating-point (it's better/more ap...

tannergoodingOP•10/21/23, 10:23 PM

the other benefit of this, is that it also better meshes with GPU compute
doing integers on the GPU is generally a bad time, and not always well supported

Perksey•10/21/23, 10:23 PM

it's worth noting there is some precedent to multiple types in silk maths e.g. see

Box2D

Box2D

Rectangle

Rectangle

Ttannergooding the other benefit of this, is that it also better meshes with GPU compute doing ...

tannergoodingOP•10/21/23, 10:25 PM

(not well supported meaning, GPUs don't often have many integer compute units; so you're often getting 25% of the throughput by using integers)

Kai•10/21/23, 10:27 PM

That's the other thing, and I'd need to do have a look around there. How important is it to have

Vector3<T>

Vector3<T>

including integers to avoid extra overloads in bindings?
@Perksey do you have a clue? I'm fairly confident that there's a couple of cases in Vk that take Vector3<T> and you get to put whatever type

khitiara•10/21/23, 10:27 PM

oh hmm

khitiara•10/21/23, 10:27 PM

im not remembering anything

Kai•10/21/23, 10:28 PM

Cause Silk isn't just about extending the BCL maths to vectors here, we also (and maybe primarily) want this to work with bindings so CPUGPU is fairly painless

tannergoodingOP•10/21/23, 10:28 PM

extending the BCL maths to vectors here

(this is happening in .NET 9, it's already been partially started in an OOB in 8)

Kai•10/21/23, 10:30 PM

given your preferred design I'm assuming float only

tannergoodingOP•10/21/23, 10:30 PM

for the .NET 8 OOB feature it's float
but for .NET 9 it will be all floating-point types

KKai That's the other thing, and I'd need to do have a look around there. How importa...

Perksey•10/21/23, 10:31 PM

we haven't discussed this in terms of SilkX yet. for OpenGL i know there are a lot of manual overloads today, i'll check BT to see if there's any automated ones

tannergoodingOP•10/21/23, 10:32 PM

the OOB feature is

TensorPrimitives

TensorPrimitives

, which is math APIs over

ROSpan<T>

ROSpan<T>

(so

TensorPrimitives.Log(ROSpan<float> x, Span<float> destination)

TensorPrimitives.Log(ROSpan<float> x, Span<float> destination)

)
in .NET 9, that will expand to

where T : IFloatingPointIeee754<T>

where T : IFloatingPointIeee754<T>

and also to

Vector128.Log(Vector128<float> x)

Vector128.Log(Vector128<float> x)

and friends (+ double overloads)

Kai•10/21/23, 10:32 PM

floating-point types

yeah that's sort of what I ment

Ttannergooding the OOB feature is `TensorPrimitives`, which is math APIs over `ROSpan<T>` (so `...

Kai•10/21/23, 10:32 PM

ooooh that is really cool

tannergoodingOP•10/21/23, 10:32 PM

ah, well then yes
because

Cos(int)

Cos(int)

doesn't make sense

Perksey•10/21/23, 10:32 PM

doesn't appear to be any automated ones

Perksey•10/21/23, 10:33 PM

so there is technically no precedent here

PPerksey doesn't appear to be any automated ones

Kai•10/21/23, 10:33 PM

not because we will generate 10 overloads for each possible T? Or because the APIs don't have any

Perksey•10/21/23, 10:33 PM

BuildTools does not generate any Silk.NET.Maths or System.Numerics overloads today

tannergoodingOP•10/21/23, 10:33 PM

we'll likely have some APIs where it can minimally make sense for integers though
like

Log2(int)

Log2(int)

(and already have these for scalars, of course)

Kai•10/21/23, 10:38 PM

hrm I'll think this over but it's annoyingly a great argument for making more types. Hard to imagine what the rest of the types look like if we were to have Point + Vector. There is some interesting properties if we separate there also

Kai•10/21/23, 10:40 PM

Also thanks as always Tanner for discussing all this and sharing your wisdom :)

tannergoodingOP•10/21/23, 10:52 PM

Sure thing! And I’m definitely not always right nor is the BCL and it’s entire possible there’s alternatives that no one has considered yet.

I’m sure silk will end up with something that satisfies most of the user base regardless of what’s decided

nora•10/21/23, 11:32 PM

are there any plans to make these apis distinct between namespaces?

nora•10/21/23, 11:32 PM

or is this a case of me cramming everything into one file

Perksey•10/21/23, 11:33 PM

are there any plans to make these apis distinct between namespaces?

I think you've answered your own question

Perksey•10/21/23, 11:34 PM

namespaces are the language's built-in feature for disambiguating APIs

nora•10/21/23, 11:34 PM

ah i suppose i had a bit of a brain lapse

nora•10/21/23, 11:34 PM

my bad

Perksey•10/21/23, 11:35 PM

wow, that worked?

Perksey•10/21/23, 11:35 PM

haha no worries, not the first time we have got that complaint

nora•10/21/23, 11:36 PM

i was just a bit concerned because this doesnt look the best but its not the end of the world

nora•10/21/23, 11:36 PM

migrating some of my code to the silk apis

Perksey•10/21/23, 11:37 PM

yeah, there are other things you can do as well like using SpvCompiler = Silk.NET.SPIRV.Cross.Compilerusing SpvCompiler = Silk.NET.SPIRV.Cross.Compiler

nora•10/21/23, 11:37 PM

true

Perksey•10/21/23, 11:37 PM

but generally namespaces exist for a reason and i usually have a really hard time conveying that to people

Perksey•10/21/23, 11:37 PM

primarily because unlike something like C++, people don't really think about them in C#

PPerksey but generally namespaces exist for a reason and i usually have a really hard tim...

tannergoodingOP•10/22/23, 12:42 AM

Noting, however, that if two namespaces are expected to be commonly used together, it’s generally best practice to avoid conflicts and avoid explicitly disambiguate the real name instead

tannergoodingOP•10/22/23, 12:42 AM

No clue if that’s the case here or not, but if it is then API review would ask us to reconsider the names

Perksey•10/22/23, 12:43 AM

it’s an odd case

maybe I'm contrasting AAA vs indie development too much but, length is a core need for using vector

Similar Threads