Jump to content

3D Rendering with the new screen tech


Recommended Posts

Hey all! So I've been playing around with the new screen tech on the PTS, and decided to try to create a basic 3D renderer. It was a bit of a pain because there's a 50,000 character limit, and no vector libraries in place (yet?) but it was a fun challenge, and it runs fairly well!

 

 

 

Anyone else playing around with the new screens yet?

Link to comment
Share on other sites

Nice project. Reminds me of old skool demo scene stuff.

But I also have to be a bit of a downer, since I have a feeling CSS 3D transformations would not only be simpler, but also much faster.

Link to comment
Share on other sites

2 hours ago, CptLoRes said:

Nice project. Reminds me of old skool demo scene stuff.

But I also have to be a bit of a downer, since I have a feeling CSS 3D transformations would not only be simpler, but also much faster.

Simpler, quite probably! This was quite a lot of work =D

 

But faster? I honestly really doubt it. This is some very very basic level stuff, there's very few operations involved in each of these steps, and the amount of data being transferred over the server is also minimal, just the 50 kb (45kb of which is the teapot itself) one time, then the client's computer handles all of the processing. That said, it's also pretty limited in its ability, I kept the code pretty tight and efficient, but the trade-off is it isn't super versatile. It can handle any OBJ file that has faces that only have 3 vertices each. I'll expand it out later (probably) but the more versatile you get the slower and more bulky it becomes.

 

The loading step at the beginning could probably go 10-100x faster, I seriously lowballed how much processing to do at each step, I may optimize that later, I just wanted to be absolutely certain it wouldn't overload!

Link to comment
Share on other sites

It is a bit of an apples to oranges to bananas comparison..

In most browser CSS/SVG transform is GPU accelerated, so that would definitively be A LOT faster. But at the same time I have a feeling that the CSS/SVG implementation in DU is not using the GPU, so then it becomes a question on how optimized the software fallback is.

 

And of course while importing your own 3d engine is seriously cool, it also leaves less script space for other stuff.

If NQ really wanted people to make cool screen projects they should add support for webassembly and webgl, instead of re-making functionality themselfs. But that is not their way.

Link to comment
Share on other sites

10 hours ago, CptLoRes said:

It is a bit of an apples to oranges to bananas comparison..

In most browser CSS/SVG transform is GPU accelerated, so that would definitively be A LOT faster. But at the same time I have a feeling that the CSS/SVG implementation in DU is not using the GPU, so then it becomes a question on how optimized the software fallback is.

 

And of course while importing your own 3d engine is seriously cool, it also leaves less script space for other stuff.

If NQ really wanted people to make cool screen projects they should add support for webassembly and webgl, instead of re-making functionality themselfs. But that is not their way.

 

"... HTML/CSS/Javascript is a group that forms a UI technology. For reasons beyond the scope of this topic we do not allow the use of Javascript inside the screen units. When you remove Javascript, the group effectively becomes a not so efficient vector image drawing technology which we have very little control over in terms of rendering. " - NQ

Meanwhile Coherent ui:

Coherent GT incorporates the proprietary Renoir graphics library and performs all rendering on the GPU. Renoir backends are provided for all major graphics APIs and multi-threaded rendering engines. Users can also customize the low-level rendering code and even write their own backend that uses the application engine. https://coherent-labs.com/Documentation/cpp-gt/db/d12/rendering_guide.html

Link to comment
Share on other sites

11 hours ago, CptLoRes said:

In most browser CSS/SVG transform is GPU accelerated, so that would definitively be A LOT faster.

 

It could be that they are not using gpu acceleration, but we also know that they are not using databinding, which means the whole DOM tree gets refreshed and stored in memory on every frame.... smh....

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...