All these experiments are so cool! Great work guys!
I am wondering if the MoltenVK render and the future new editor extensions will also bring to the table node based shader creation? Just wondering…
Vulkan/MoltenVK wont really do much for such a feature I’m afraid, I’m building it on top of the same render API so it Will have the same capabilities as the current renderer. But it does opens up a bunch of other potentielly cool features down the line that I’m excited about
One (boring) thing I’m particularily excited about is that we get more than 4k textures on iOS. On iOS, OpenGL is restricted to 4k textures, even if the hardware supports more. Yay! More space for huge keyframe animations!
Before you release the new raycast API I would suggest making rays hit “trigger” collision objects too. This will not hurt anything, but make the new ray casts more flexible.
I haven’t tried it specifically, but I just assume it works since it’s the same raycast code being invoked.
This flew a bit under the radar but actually shipped in 1.2.149 under the issue DEF-3618 - Preloader path cache.
In case anyone was waiting for this.
This Friday was an Exploration day and I decided to implement gamepads for html5.
It’s not done yet, but I have the first results:
wooooow glad to hear!
Got back to doing a bit of vulkan work this sprint, so thought I should share the progress so far. I’m currently looking into dealing with the render pipeline state management for things like culling and depth testing.
Are multiple material IDs per model on any roadmap for 3D?
I don’t have the roadmap in front of me, but I don’t think so. @britzl might know
No, it’s not on the roadmap. How would it be used?
In the model you can select a material ID # for certain faces. Then in the model you would be able to assign a material per material ID. So you can have a model with completely different material logic for different areas.
It’s one way to get separation of rendering in models. Another way is to map different shader logic based on color coded texture regions for material IDs that way, or to use a PBR approach.
Hey all,
here’s a little teaser Tuesday sneak peak of joints support:
Here you see some classic spring joints, but also hinge joints with motors enabled on the “car”.
We recently took a new stab at the design for joints/constraints, based on input from @Mathias_Westerdahl previous exploration, and are now in implementation mode. We want to keep the scope down so we can deliver it as soon as possible. The current plan is;
- Supply a runtime API in the initial release, and having the editor/build-time joint creation as a separate task.
- Initial release will only support joints in 2D physics.
Can’t promise a definite release date, but it is being actively worked on so expect “soon”.
whoa! awesome!!
Wow! Something really great! opening new possibilities!
Finally
One more teaser from @sven , but I don’t know why he doesn’t want to share it himself (I decided to steal his likes =)) )
New API for changing the vector of gravity in runtime: