Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comparison to three kt #1

Open
altavir opened this issue May 27, 2019 · 23 comments
Open

Comparison to three kt #1

altavir opened this issue May 27, 2019 · 23 comments

Comments

@altavir
Copy link

altavir commented May 27, 2019

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
Copy link
Owner

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.

@altavir
Copy link
Author

altavir commented May 27, 2019

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

@markaren
Copy link

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

@nimloth05
Copy link
Owner

@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
Copy link

markaren commented May 27, 2019

I wrote everything by hand.

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

@nimloth05
Copy link
Owner

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
Copy link
Author

altavir commented May 27, 2019

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
Copy link
Owner

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
Copy link

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
Copy link
Author

altavir commented May 27, 2019

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

@markaren
Copy link

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

@nimloth05
Copy link
Owner

nimloth05 commented May 27, 2019

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 (-:

@markaren
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

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

@markaren
Copy link

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

@markaren
Copy link

@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
Copy link
Author

altavir commented Jul 24, 2019

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
Copy link

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
Copy link
Author

altavir commented Jul 24, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants