Project Tiny vs BabylonJS / ThreeJS

In my company there are both Unity developers and web developers that make apps for the rest of the company.

What are the selling points of project tiny in its current state / the state it intends to be in by version 1 over other existing 3d libraries for web developers to use and vice versa? Reasons that may make a difference to developers, clients or end users.

I want to make a case to eventually use the DOTS runtime at work but I don't know enough about either to pitch it.

 

What I can say about advantage is

- It use wasm and DotS, it will scaled better than JS
- It could reuse most of unity tools and asset we have done in unity
- Visual editor, I'm not sure we have it in Babylon or Three yet
- Using C# over JS is the whole reason I personally stick with unity

Aside from that I don't think Tiny is a great choice. It limit too much capability you could do while you can have freedom using pure JS. It limit in both C# side and JS side. And don't really have timeline of releasing full version. It slow process and don't have clear future. Even the document are not clear. Right now it clearly not ready for production. Earliest would be Q2 or Q3 in this year and that was highest hope. So I don't recommend you to bother with it right now if you already have many experience in ThreeJS

 

I hope that one day we can produce WebGL-stuff with Unity in a quality as sketchfab provides.....

 

I changed from Unity to threejs a few months ago, I am glad I didnt wait for Unity. It is amazing the work they are doing but its going to take another 12 months before stable products are launched without having to rewrite the code every new update.

Will be interesting to see where it goes, but I think threejs is better.

 

I thought you could 'compile' JS to WASM and DOTS was limited by WASM to a low or single thread count until a certain browser features was enabled/released?

 

I could say that DotS pipeline is optimized in general. It streamline most overhead that normal OOP code would faced, especially dynamic system like JS, into job system that pass around struct reference (which is faster than reference type and has no GC footprint, unlike GameObject and JS object)

Thread parallelism just boost perf to another level and even it not required, it expectable that support will eventually came anyway

 

I hope that one day we can produce WebGL-stuff with Unity in a quality as Unity 4.6 provided...

(I still mourn the day when Unity WebPlayer was killed off . 4 years ago Unity had excellent, fast, export to web, that Just Worked. Still haven't regained what was lost! Hopefully in 2020...)

 

Don´t agree, installing Webplayer was a big hurdle ...

 

Agreed on 1st-time install. Which is why WebGL is a much better tech going forwards.

But many of us worked in environments where webplayer install could be safely assumed (or required!). As a developer, it worked excellently.

 

It would be great if all browsers just worked with it, if they could dynamically allocate more memory and threads when needed. Or have some way of letting your game/app know it has to work within a memory footprint or on limited threads allowing you to limit what it does.

Mind you last I checked compiling to WASM was crazy slow compared to compiling and building to native, maybe there are just too many steps in the build process C# -> IL -> IL2CPP -> CPP -> JS(?) -> WASM.

? Note sure about JS as I think this is optional for WebGL to JS.

If we could just build C# -> IL -> WASM it would massively reduce the build pipeline?

 

@Arowx First, new version of tiny are now really truely so fast to build wasm, unlike wasm we used to build normally, but it trade off with very strict subset of dotnet and very limited functionality of unity

Second, what you try to talk about is actually exist, it is Blazor with MonoWasm. But unity does not use it. Still you could try that, just google for Blazor webgl canvas

 

Is this actually compilation to WASM or using WASM as a virtual machine to run IL code or JIT compilation to WASM?

 

Sorry but I don't know about that detailed implementation

 

As far as I can tell it's C# to CPP (via il2cpp) and then CPP to WASM via Enscripten.

 

MonoWasm is the wasm version of the Mono runtime and can execute normal .NET dll in the browser.
But so far i know, the future of Blazor is .NET core and compile the entire application to WASM with tree shaking for small filesize.

 

I think PlayCanvas must be doing something right (efficiently). I'm able to run those scenes and projects on just about any mobile, laptop or desktop device with good frame rates.

 

Absolutely!
(See my little archviz here)

 

Thats cool!
But its unclear to me if you made this with PlayCanvas, or its simply Sketchfab...
Could you elaborate a little about your archviz example please?

 

Ups sorry, it´s done in Sketchfab NOT Playcanvas - my mistake.
No matter, both are "doing something right"

 

Hi, I am debating between unity and three.js, I will do a game similar to sims with multi player, with customizeable scenes, which one will be easier do you think?

 

threejs is just library, purely library, couldn't compare with unity at all. Unity is full fledged editor and far more easier to start develop actual app

The drawback is unity have its complicate library that don't guarantee to work on all platform. Also complicate and annoying build system

If you really a beginner and want to develop web game, I suggest playcanvas or construct which is made for making web game, unity are more focused on PC and mobile, some for console, and hardly for web

ps. I think webapp editor like playcanvas using threejs internally. As I told you it was pure library, not suit for develop game with it directly, but people have used it as base of many things

 

Coincidentally PlayCanvas has just had some major updates. One of them is increasing the free storage by quite a bit. I think the most important one they hid behind a paywall prior. The ability to download the source files for self-hosting. Now that is also in the free tier.

 

Thanks for the reply, yes I am a newbie for game dev but have coding experience(10+ y), I will generate my scenes programmatically so do you think I will need editor that much? So my thinking is if I need to generate stuff programatically why not go more low level.

 

I get where you're coming from but there's so many aspects of game development that really shouldn't be done at just low levels like animations, audio grouping and mixing and plenty of other small workflows that add up to really slow you down if you don't use a visual editor.

 

Thanks I have 2 concerns

1. Multiplayer support, networking
2. Programmatically change scene, my app(in browser) will be similar to sims and different size of the group will see different set of rooms, and as the group size increase I need to add new rooms programmatically,

I am trying to answer "which one do I need to use for faster development/performance?"