Comparison to three kt
altavir opened this issue · comments
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.
My library works by parsing the docs. This has the nice effect that:
- Declarations contains API documentation
- If a new threejs version is released, I only regenerate my declarations.
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.
Steel, it would make more sense if you contribute to the existing project instead of creating one from scratch.
Well, if he is able to successfully auto-generate the required files I'd say this project would supersede mine.
@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.
I wrote everything by hand.
But, really it's not that many files. The problem is keeping them up to date.
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.
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.
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.
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.
Why do you need it? Threejs looks good as far as js libraries go.
It's mainly for the JVM part. The Javascript would be for "free"
My dream as well actually, but there are several possibilities:
- Rewrite threejs in kotlin, as @altavir suggested or
- Write some sort of common API and delegate the implementation to threejs (js) / jMonkey (jvm) To prevent the implementation of yet another scene graph project...
One could also think about porting libgdx to kotlin and built something on top... IDK (-:
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.
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...
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..
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...
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.
Maybe you can get some inspiration from libgdx? They have exactly the same problem...
Perhaps. But I don't think I will follow up on this any time soon.
@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 :)
This is a super-interesting project. And I see some important possibilities:
- 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.
- We can create a multi-platform build, which uses JS bindings for browser and GL/FX implementation for desktop/anroid with the same API.
- 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?
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
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.