nimloth05 / threejs-kotlin-binding

Binding for threejs in kotlin
3 stars 2 forks source link

Comparison to three kt #1

Open altavir opened 5 years ago

altavir commented 5 years ago

Hello, we are currently using a fork of three.kt library for our needs. The library is good, but sadly not maintained anymore. Could you say if your implementation is different from three.kt. If not, is it possible to join forces with @markaren and support a single library instead of multiple independent projects. As users, we would like to have a single reference implementation and we would like to contribute our fixes to it.

nimloth05 commented 5 years ago

My library works by parsing the docs. This has the nice effect that:

Parsing the docs is not ideal (code is ugly for once) so parsing the d.ts files of threejs would be a better alternative (they also contain API docs) but this it not a priority ATM.

What I will implement next is support for coroutines: Access threejs loaders via a coroutine API.

altavir commented 5 years ago

Steel, it would make more sense if you contribute to the existing project instead of creating one from scratch.

markaren commented 5 years ago

Well, if he is able to successfully auto-generate the required files I'd say this project would supersede mine.

nimloth05 commented 5 years ago

@markaren Is your binding written by hand? Or did you use ts2kt for a head start?

And yes, I auto generate the files, its in the parser part of the project.

markaren commented 5 years ago

I wrote everything by hand.

But, really it's not that many files. The problem is keeping them up to date.

nimloth05 commented 5 years ago

Respect, I started with that one evening but after "porting" Vector3 I was looking for an alternative. ts2kt didn't work so I parsed the docs, initial dev time was around 3 days.

altavir commented 5 years ago

Guys, I am a user here. We have several fixes for webpack compatibility, which we can contribute (for example we use three-full instead of three for dependency), but all in all, it would be good to have single library. Three.kt also sounds better.

nimloth05 commented 5 years ago

GitHub is dark and full of duplicates. But in all seriousness: You are right, binding is not so good a name, wrapper would have been better. With the next release of three (r105) I will most likely update the maven coordinates at least to something like threejs-wrapper or something, I will update the readme in case. three.kt sounds like port to kotin for me. But in the end, its all just taste and everyone is can do what he/she wants.

markaren commented 5 years ago

Off-topic: A dream of mine is to actually rewrite three.js in Kotlin with both OpenGL (JVM) and WebGL (JavaScript) backends. This should be manageable, since only the WebGLRenderer stuff is language specific.

altavir commented 5 years ago

Why do you need it? Threejs looks good as far as js libraries go.

markaren commented 5 years ago

It's mainly for the JVM part. The Javascript would be for "free"

nimloth05 commented 5 years ago

My dream as well actually, but there are several possibilities:

One could also think about porting libgdx to kotlin and built something on top... IDK (-:

markaren commented 5 years ago

My main motivation would actually be to replace JMonkey and libgdx for simple 3D in Java. Both of which are overly complex to start with when you just want simple visualization.

nimloth05 commented 5 years ago

I guess the goals are very different for these projects. I mean Monkey tries to be a full blown game engine (one would actually only need the scene graph part for a common interface with threejs) and libgdx, well, is more of a game library I guess (since it doesn't contain a 3D scene graph)

So your goal would actually be just a "renderer" (3D scene graph) library accessible for JS and JVM implemented in kotlin? It sounds easy at first, but looking at all the github issues from threejs and all its contributor I think its still a big project...

markaren commented 5 years ago

I actually started some years ago rewriting it in Java: https://bitbucket.org/laht/threej/src/master/ I think I got most of the core library down. The problem is to translate the WebGL code to equivalent OpenGL code..

nimloth05 commented 5 years ago

Thats a cool start, with the converter plugin you could convert all the java code to kotlin. For the openGl problem - could lwjgl maybe help? I'm not an openGl expert so I can actually not comment on that, but it would be cool to have a MPP renderer at hand...

markaren commented 5 years ago

Yes, I would use lwjgl. But that just gives you access to the OpenGL API. You still need to map the WebGL (OpenGL ES) to some OpenGL version.

nimloth05 commented 5 years ago

Maybe you can get some inspiration from libgdx? They have exactly the same problem...

markaren commented 5 years ago

Perhaps. But I don't think I will follow up on this any time soon.

markaren commented 5 years ago

@nimloth05 I've used my vacation porting three.js to Kotlin/JVM ^^ https://github.com/markaren/three.kt

The basic works. But still alot to do. Just letting you know :)

altavir commented 5 years ago

This is a super-interesting project. And I see some important possibilities:

  1. We should see if it is possible to abstract rendering mechanics and to be able to substitute direct opengl rendering with JavaFX. It is required for more complicated non-game projects.
  2. We can create a multi-platform build, which uses JS bindings for browser and GL/FX implementation for desktop/anroid with the same API.
  3. We can then add native platform with bindings for native opengl and cover all platforms with the same API.

If those are successful, the result could have a tremendous impact. Imagine - common code for 3D rendering everywhere. My laboratory would be really interested in it. For now I can contribute a multi-platform build setup.

Should we create a channel in kotlin forum for discussions?

markaren commented 5 years ago

I made a gitter chatroom for my repo, which could potentially be used: https://gitter.im/markaren/three.kt?utm_source=share-link&utm_medium=link&utm_campaign=share-link

altavir commented 5 years ago

The kotlin slack is better because we could painlessly include other kotlin developers. As far as I can understand, there are a lot of people interested in a multi-platform game development and 3D visualization. But we can start with gitter if you want.