Have portals working nicely.

Started by
8 comments, last by Paul Griffiths 7 years, 2 months ago

Thought I would show an image of my current portals implementation.

Have an interesting effect with infinite regressed portals, may make an interesting space flying race game...
Been at it for days, been hard work but can fly through portals with no problems.

Engine has deferred renderer, multiple lighting and multiple shadows.

Untitled.jpg

Advertisement

pic.jpg

I've now implemented clipping for lighting and shadows for the portals, now lights and shadows can only enter and leave the front of the portals and not to the sides, which if I'm correct is a world first?

pic2.jpg

Starting to look pretty good.
"Great job"

Starting to look pretty good.
"Great job"

Thanks, I've been working hard at it.

I've updated the lighting, had a problem with shadows looking too pronounced.

Also adjusted the clipping as was not right as you can see in the above image.

You all may be wondering why I'm obsessed with portals? It's because I want to create the worlds first 3D GUI system, Windows, Scroll Bars, Buttons etc. all in 3D and portals are required for the clipping.

Going to release the engine for applications and games.

pic4.jpgpic3.jpgpic5.jpg

pic6.jpg

Thought I would show a latest screenshot:

Spending most of my time optimising the speed of the engine and it's fast. Culled if portals are off-screen and if outside the view of the portal before it too.

Enjoying it, getting advanced.

pic8.jpg

pic7.jpg

It's because I want to create the worlds first 3D GUI system, Windows, Scroll Bars, Buttons etc. all in 3D

If I remember well, there were several attempts on doing this. I can remember the name 3dwm, which finally moved to another goal, before disappearing. Then some desktops introduced some 3D fancy things and I don't know what happened to these things.

I guess all these attempts revealed that at the end there is no real "user-play" gains going this way.

I hope your project will meet a better ending.

I guess all these attempts revealed that at the end there is no real "user-play" gains going this way.

I disagree, a mixture of 3D GUI and 3D models would be good, I have great interest in audio applications so be good to build 3D GUI audio studio with virtual 3D synthesizers, keyboards, drum kits etc.

?360 degree 3D would give more real-estate than a 2D window.

It's easier and quicker to program a button being pushed by simply moving it back than it is to design 2 button states in a 2D window system. Quicker programming means applications with more functionality.

Though adding things like glowing/blooming buttons etc. will increase the programming beyond 2D programming but will look good.

gui.jpg

gui2.jpg
gui3.jpg
I disagree, a mixture of 3D GUI and 3D models would be good, I have great interest in audio applications so be good to build 3D GUI audio studio with virtual 3D synthesizers, keyboards, drum kits etc. ?360 degree 3D would give more real-estate than a 2D window. It's easier and quicker to program a button being pushed by simply moving it back than it is to design 2 button states in a 2D window system. Quicker programming means applications with more functionality. Though adding things like glowing/blooming buttons etc. will increase the programming beyond 2D programming but will look good.

I did not say that it has been proven 3D will give no improvement over 2D for GUIs. I just did say that passed attempts failed most certainly because the way they did it did not reveal any usability improvement. Take it more than a warning, than a "don't do it".

For the push button story, there are pros and cons. You consume far less the CPU and the GPU by just switching between two little images stored in (some) memory, than having to do calculations both on CPU and GPU.

Here's the latest screenshot of my portals implementation.

Producing many portals is hard, having portals within portals is even harder, a portal can be at any place and go to any scene and then back again, each portal has multiple instances, so does each scene and each model.

For every portal you need 2 copies of every scene forward and then back as it's a view into the complete universe both ways. If you have 10 scenes and 10 portals within portals, that's 20 scene instances for each portal, 10 going forward and 10 going back. So that's 200 scene instances in total.

If you have 200 scene instances you may think I'm doing something wrong, no, you can do it with just a single instance but calculating all the portals each frame dramatically reduces the framerate. So you have many instances and only need to update the portals maths when you go through a portal. This speeds up the framerate dramatically.

There's a lot of pixel discarding going on in the shaders, and lots of culling to keep up the framerate.

I've fixed the lighting and shadows, working well now, seamless!

pic12.jpg

pic13.jpg

pic11.jpg

This topic is closed to new replies.

Advertisement