★ TouchArcade needs your help. Click here to support us on Patreon.

Comments on home-brewed 3d engine?

01-28-2015, 11:36 AM
#1
Joined: Dec 2014
Posts: 24
Comments on home-brewed 3d engine?

Sorry, here we go, long post....

For our recent App launched in December, 'Tip & Tumble', we (as in 'I') wrote our own OpenGL-based engine. Whilst I've been programming for decades I had no previous experience of OpenGL or any other computer graphics, so I'd be interested in any comments/feedback on its effectiveness. Obviously it would have been easier to use a commercial engine, and I need to reconsider that option again for future Apps.

I was particularly pleased with the 'rolling balls' effect. I had to support many rolling balls at once, and rotating multiple fully rendered and lit spheres with surface markings would have been challenging, performance-wise. It is actually achieved by a 'static' sprite for each sphere, i.e. a flat disc, wrapped in a cuboid frame with a separate 'dot' sprite on each face of the cube. While the disc simply glides with a camera-facing translation, the enclosing cube is accurately rotated. This allows for a smoothly rendered sphere with consistent lighting effects on the dots as it rolls, yet relatively few polygons. It's not perfect, but the artefacts are not too noticeable.

I have no idea whether that approach was original, or if there would have been better or easier ways! I don't even know for sure if I'm using the right terminology... as confessed, this is all new to me, learned from a pretty good book I found on Amazon.

Here is a YouTube clip. If you want to see it in the App, whilst you can buy it today and we won't complain, you may want to wait a couple of days as we plan to do a 'free for a day' promotion this Friday/Saturday. Once that promotion is in effect I will announce in appropriate TA Forum, and update this thread too if there's been any dialogue.


Youtube link | Pop Up




Cheers,

Bill
01-28-2015, 12:16 PM
#2
Joined: Apr 2009
Location: Pennsylvania
Posts: 1,006
Looks pretty, but I'm curious if you bothered trying the more obvious brute force approach with real geometry/lighting, and if so, how it compared cosmetically and performance-wise.

01-28-2015, 12:27 PM
#3
Joined: Dec 2014
Posts: 24
Quote:
Originally Posted by Stroffolino View Post
Looks pretty, but I'm curious if you bothered trying the more obvious brute force approach with real geometry/lighting, and if so, how it compared cosmetically and performance-wise.
Well, sort of.


The sphere sprites were rendered using a massive (10,000s -100,000s I can't remember) polygon count, and brute force in the simulator, then the screenshot captured and used for the sprite. That allowed the lighting effects to be fairly correct and consistent with the rest of the scene.

The brute force render took something like several seconds for each sphere. Obviously the code could have been optimised, polygon count reduced, and the device may have been faster, but it seemed unlikely that it would ever improve enough to render multiple spheres at 60fps.
01-28-2015, 12:43 PM
#4
Joined: Apr 2009
Location: Pennsylvania
Posts: 1,006
Simulator is very sluggish. You could probably have gotten away with a "good enough" real time sphere renderer on devices by using a more modest poly count, but I like what you did, as it gives what appear to be perfectly rendered/aliased spheres without you having to even worry about performance.

Quote:
Originally Posted by Idle Complexities View Post
Well, sort of.


The sphere sprites were rendered using a massive (10,000s -100,000s I can't remember) polygon count, and brute force in the simulator, then the screenshot captured and used for the sprite. That allowed the lighting effects to be fairly correct and consistent with the rest of the scene.

The brute force render took something like several seconds for each sphere. Obviously the code could have been optimised, polygon count reduced, and the device may have been faster, but it seemed unlikely that it would ever improve enough to render multiple spheres at 60fps.
01-28-2015, 03:21 PM
#5
Joined: Dec 2014
Posts: 24
Quote:
Originally Posted by Stroffolino View Post
Simulator is very sluggish. You could probably have gotten away with a "good enough" real time sphere renderer on devices by using a more modest poly count, but I like what you did, as it gives what appear to be perfectly rendered/aliased spheres without you having to even worry about performance.
Thinking harder to recollect what I did, you may be right. That 'one-off' brute force render also included drawing the sphere, as well as rendering it.

I'm sure there's MUCH better ways of drawing spheres, but my simplistic approach was to start with a very week approximation to a sphere (six triangles in a circle), and then iterate, repeatedly subdividing each triangle, experimenting with iteration depth until the end-result looked satisfactory. The iterative drawing is probably where the CPU time went, whereas that obviously would not have been needed at run time in deployed App.

No regrets though, a bottleneck avoided has to be better than a bottleneck optimised.

Thanks for feedback.
01-31-2015, 04:03 AM
#6
Joined: Sep 2010
Location: Morestel, France
Posts: 572
It was a good learning exercise for you. Graphically, it is lacking lighting and shadows. A simple sprite projected on the board surface will make your game look like 100x more solid.

I'm using my own engine too. It's more advance as your one as I've been doing it for a long time (and it was my job to write game engine). But you should have a look, I'm sure you can grab a few tips there: http://forums.toucharcade.com/showthread.php?t=253948

JC
01-31-2015, 04:45 AM
#7
Joined: Dec 2014
Posts: 24
Thanks,

I'm not sure what we'll be doing for next App, there's a couple of ideas in mjnd. But for at least one of those, the suggestion for shadows is worth exploring.

I dismissed the shadows as 'too complex' for T&T as the shadows would ideally 'land' correctly not just on the floor, but also on the sloping wedges, and the walls. But think I can see how it could be done, maybe gave in too easily!
02-01-2015, 05:10 AM
#8
Joined: Sep 2010
Location: Morestel, France
Posts: 572
for the shadows... 2 solutions:

a) create a texture of a blurry blob and cast it to your geometry for each sphere. It means re-draw your geometry N+1 (N being the number os shperes casting shadows). For each new passes you are using your mesh but force the texture to be the blob shadow. Also, you need to change the uv but it is dead simple to convert your sphere into the uv metric of your mesh.

b) similar to a) but you draw your geometry only twice (instead of N+1). You create just one big shadow map with all your shadows on it. You can do it in software, you won't have much cpu requiered for that. Make your texture low res anyway, it will look better as it give it a blurry look. then draw your mesh using that shadow map, the uv are even easier to compute than a)

JC