Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dominic Fischer
    @Dominaezzz
    Oh cool!
    Lars Ivar Hatledal
    @markaren
    I've also added STL and OBJ loaders today
    The OBJ loader is 99% multiplatform,
    Dominic Fischer
    @Dominaezzz
    Yeah, we just need a multiplatform readText.
    About the data classes thing. I guess the real question is, do we want to match the three.js api exactly or write Kotlin's take on three.js?
    Lars Ivar Hatledal
    @markaren
    true that. I think we will start to change more than we think along the road
    Lars Ivar Hatledal
    @markaren
    @altavir I just added a working JavaFX demo. Thought you'd might be interessted.
    Alexander Nozik
    @altavir
    @markaren I definitely am. I took a few days timeout from this work to cover other bases, but we will start working on desktop version as soon as we have working JS prototype.
    Lars Ivar Hatledal
    @markaren
    The JavaFX thingy is not developed any more though, and it was not very pretty tbh. But, but..
    Alexander Nozik
    @altavir
    It is developed quite thoroughly by Gluon, and tornadofx is quite popular
    Lars Ivar Hatledal
    @markaren
    sorry, I was talking about jfxgl
    Lars Ivar Hatledal
    @markaren
    @Dominaezzz Uhm, tests are not working after migration to kotlin gradle buildscripts. They will succeed no matter what.. Also I experienced that setting compile target 1.8 had no effect any longer.
    Lars Ivar Hatledal
    @markaren
    Or a clean and build might have helped, although I don't seem to be able to load files from the test resources..
    Woopsie.. The tests are in core, so we are seeing the old resource bug again.
    Lars Ivar Hatledal
    @markaren
    image.png
    OBJLoader now with proper MTL support :)
    Alexander Nozik
    @altavir
    @markaren :thumbsup:
    Dominic Fischer
    @Dominaezzz
    Ah, they'll have to be run via gradle jvmTest.
    Lars Ivar Hatledal
    @markaren
    yeah, I figured
    Lars Ivar Hatledal
    @markaren
    @Dominaezzz when you have spare time, can you help me set up a branch with kotlinx.io support? I am unable to make the classes appear even though I have added the dependency.
    Dominic Fischer
    @Dominaezzz
    No problem. Should be able to set something up today.
    Lars Ivar Hatledal
    @markaren
    great
    Lars Ivar Hatledal
    @markaren
    I think BufferAttribute needs to be platform specific. Using the IoBuffer there seems not so easy as it does not have indexed read or write, and I guess the readDirect which exposes the platform dependent backing buffer may or may not be available on all platforms?
    Dominic Fischer
    @Dominaezzz
    It's available on all platforms.
    There's going to be an indexable buffer at some point but it's not ready yet. Kotlin/kotlinx-io#39
    Lars Ivar Hatledal
    @markaren
    We could use Arrays in BufferAttribute as I did in the beginning while we are waiting for either indexed buffers or platform specific solution. At least then we can move more classes over to common. Performance does not have to come first
    Lars Ivar Hatledal
    @markaren
    Damn, moving Material to common makes accessing clone() from JVM impossible as it chrases somehow with Javas Cloneable (JVM project thinks clone is protected while it's not)
    Or forget it. By explicitly having it as an import in Material it worked again. However, the IDE will probably "optimize" the import again, making it an issue..
    Lars Ivar Hatledal
    @markaren
    Import alias fixed it!
    Lars Ivar Hatledal
    @markaren
    Aight, most classes now reside in common module.
    Dominic Fischer
    @Dominaezzz
    Woo!
    Alexander Nozik
    @altavir
    I started to play a little with attaching JS implementation. It looks like all we need is to add a new Renderer implementation and bind it to three.js. The problem is that renderer does not have any methods right now.
    Also I had a very brief glimpse at Buffers and BufferGeometries implementation. Buffers could be significantly opttimized on JVM using ByteBuffer and appropriate views. I can contribute something later for that. Also Kotlin allows to add thin wrappers on top of BufferAttributes and allow them to be used the same way as regualar Geometry in js. It is done via extension functions and properties.
    Dominic Fischer
    @Dominaezzz
    Would it work from Java?
    Lars Ivar Hatledal
    @markaren
    Renderer in common is just a marker interface right now.
    JVM did use ByteBuffer at one point. I wanted to move more code to common, so the easiest solution is to use Arrays as a temporary solution
    Lars Ivar Hatledal
    @markaren
    And I also think the JS target needs to wrap three.js. Perhaps not just the renderer, but everything. All three.kt classes could have an interface?
    But I don't understand you last part @altavir .
    Lars Ivar Hatledal
    @markaren
    But honestly I think it will be hard to support all 3 targets. JVM and Native would be ok. But JS is an issue. Either you implement everything in Kotlin as with JVM and Native, but then the JS three.kt would be worse than using three.js with time. As three.js would grow further and further from it. Or you wrap three.js, but then the JVM and Native targets are held hostage of the three.js API. Perhaps we want to change it a little bit..
    Your thoughts?
    Alexander Nozik
    @altavir
    The problem with wrapping three is that then we have duplicating classes and it gets really hard to support. The correct way would be to use common logic and expect/actual mechanics for key concepts like buffers.

    Would it work from Java?

    It would work as static functions. Not quite usable, but I am talking only about syntactic sugar, not core functionality

    Lars Ivar Hatledal
    @markaren
    But why would anyone use three.kt/JS when three.js or three.js with Kotlin wrapper would have more features, less bugs etc..
    Alexander Nozik
    @altavir
    I would use it because I need a multiplatform application. I want to write common logic and only replace renderer
    Dominic Fischer
    @Dominaezzz
    I guess we're back to this same question. Do we want three.js in Kotlin or Kotlin's take on three.js? (I quite like the latter).
    Alexander Nozik
    @altavir
    I think that the only question is the performance. Three.js is optimized for JS. On JVM we need much less optimizations.
    Lars Ivar Hatledal
    @markaren
    I need some assistance with the maven publication stuff @altavir @Dominaezzz. I have a bintray repo which I'm able to upload to. But it only inlcudes the pom. And if I do as https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#publishing-a-multiplatform-library sais thn I have no named publication to provide the bintray plugin
    Lars Ivar Hatledal
    @markaren
    Figured it out!
    Lars Ivar Hatledal
    @markaren
    image.png
    The API is a bit iffy in Java, but I managed to do that ;)