Sign in to follow this  
Unduli

Headless Server Side Software Renderer

Recommended Posts

Hello there,

 

  As title partly suggests, I am looking for a solution to render snapshot of "map" server side when it's upgraded. As it will be a browser game , not everybody will have access to webGL or will have powerful hardware to render with acceptable performance, I want to incorporate a "lite version" of map.

 

 Map will be like Simcity 4 maps ( trimetric projection ) and will only have terrain.

 

Landbridge_22.jpg

 

Manuel rendering is no longer an option ( at first, it would only change when map size changed but now have to change terrain data when roads are added ) , so need a reliable option. Using Chrome to render isn't either reliable or logical for server environment in my opinion, there are some alternatives like headless-gl or mesa but they seem to use X-Window as dependency.

 

So, I wondered if a truly headless software renderer (probably with C++ as node.js module) is a wise choice and if you know any existing solution. Or sticking to other solutions is failsafe enough?

 

Thanks in advance.

 

Share this post


Link to post
Share on other sites

Look at SwiftShader on GitHub. Its the software renderer used by chrome when hardware acelleration is not available, and it implements very modern software rendering techniques. Its got an interface for OpenGL ES already, which should be quite similar to any WebGL rendering you already have. I don't know what dependencies it takes on, but it should do the trick.

 

Before being purchased by Google, it was owned by Transgaming which sold it as a solution for games that wanted a fast software-fallback when users lacked sufficient 3D acceleration and for helping Windows games port to Linux or run better under Wine (part of the SwiftShader distribution is a shared library that implements the Direct3D 9 interface exactly, entirely in software).

Share this post


Link to post
Share on other sites

Sean makes a very salient point -- its not free to do this server side. The CPU costs are probably pretty minimal, and can be amortized across users, but bandwidth costs money and even small updates (assuming you chunk your map, and program your clients to deal with it) add up. Its not always worthwhile to try to please everybody -- you're going to undertake a lot of work to please a few people who will make up your largest active operational costs -- are the margins wide enough to support them? Is the opportunity cost of implementing and maintaining that support now and in the future more important than all the other work you could be doing? From a business perspective you're often better off trying to capture more people who are like your core users (e.g. those with WebGL) than by capturing entirely new segments of users (especially already marginal and ever-shrinking segments like those without WebGL) -- its just a form of economies of scale, you may want to expand your definition of who a core user is after a time, but only when you believe it'll be easier/cheaper to capture new people from the expanded definition than to continue capturing from the original.

Share this post


Link to post
Share on other sites

Just as a note: you're the one paying the bill for server-side rendering. Are the users who don't have up-to-date browser contributing enough to your financial success (directly or indirectly) to be worth the development and operation costs?

My gut says no, but my gut is calibrated for my job and not yours. :)

Also, you state "not everybody has powerful enough hardware." Do you have stats for your users? Did you collect the telemetry? Done a market study? Do you have any _factual data_ to prove your claim, or are you just making a (potentially very expensive) guess?

 

Sean makes a very salient point -- its not free to do this server side. The CPU costs are probably pretty minimal, and can be amortized across users, but bandwidth costs money and even small updates (assuming you chunk your map, and program your clients to deal with it) add up. Its not always worthwhile to try to please everybody -- you're going to undertake a lot of work to please a few people who will make up your largest active operational costs -- are the margins wide enough to support them? Is the opportunity cost of implementing and maintaining that support now and in the future more important than all the other work you could be doing? From a business perspective you're often better off trying to capture more people who are like your core users (e.g. those with WebGL) than by capturing entirely new segments of users (especially already marginal and ever-shrinking segments like those without WebGL) -- its just a form of economies of scale, you may want to expand your definition of who a core user is after a time, but only when you believe it'll be easier/cheaper to capture new people from the expanded definition than to continue capturing from the original.

 

Well, these are valid concerns and thanks for addressing them. Problem with webGL is it has restrictions (which is expected to be partly overcome at webGL 2) anyway. When this combines with poor performance of mobile browsers (especially with my future dooms day scenario of 1024x1024 map), relying on webGL only limits your userbase considerably. So my plan is making two versions of same map. (arguably like Google Maps)

 

First one is webGL version with extra goodies, other is lite version with canvas support which has virtually 100% coverage in non-ancient devices. And my point is this is just a map, it is not wise to limit yourself with webGL only for a browser game having tonnes of other features in plain HTML.

 

I was perfectly fine with manual rendering as terrain heightmap wouldn't change therefore I'd only need to render if I change map size but later realized that roads can't have slopes greater than lets say 45 deg, so need to alter terrain when building roads. So it may be a rather expensive in CPU cycles but its not that frequent. But a chunk based solution will require a CDN probably, though it's perfectly ok for webGL ones as only heightmap data will be transferred.

 

Actual features beyond mere map will require webGL for sure but I am with using canvas for map if I can manage to.

 

 

@Ravyne

 

Thanks for the link, let me check where it fits in.

Share this post


Link to post
Share on other sites

Btw, just for the records I noticed that Amazon offers instances (g2) including GPU accessible via CUDA starting from $0.65/hour on demand. (Although I seriously doubt I understand same thing from on demand :) ) It's overkill but still an option.

Share this post


Link to post
Share on other sites

Does your game need to be 3D-rendered at all? Would isometric tiles work just as well? If it could be so, maybe the best approach is to have the essential rendering done using isometric sprites, where WebGL is used only where available to provide enhanced visuals.

 

Another option might be to have the mobile clients written in some other framework that gives better access to GPU than what you get through the mobile browser -- though, I would expect the mobile browser to converge on good WebGL support -- IIRC, chrome is already a single codebase between desktop and android.

Share this post


Link to post
Share on other sites

Does your game need to be 3D-rendered at all? Would isometric tiles work just as well? If it could be so, maybe the best approach is to have the essential rendering done using isometric sprites, where WebGL is used only where available to provide enhanced visuals.

 

Another option might be to have the mobile clients written in some other framework that gives better access to GPU than what you get through the mobile browser -- though, I would expect the mobile browser to converge on good WebGL support -- IIRC, chrome is already a single codebase between desktop and android.

 

Unfortunately I hate isometric view and trimetric one serves my (current and future) purposes far better. And other than rendered terrain most of visuals are prerendered assets either used as sprite (canvas) or UVed to basic geometry (webGL) . webGL will only be exclusive for situations realtime rendering needed.

 

Having mobile apps is next phase, not feasible with my indie tech budget atm. Plan is initially having apps first for MBs of assets problem, later switch to native solutions also utilizing mobile platform features.

 

I think I decided not to make this priority (actually it can theoretically already be achieved by using three.js with canvas/software renderer fallback but performance isn't much promising) and keep looking other options.

Share this post


Link to post
Share on other sites

I don't know how complex your game is, but my personal experience has been that any mobile device that doesn't run WebGL by now probably isn't going to be nearly fast enough to run a javascript game of non-trivial runtime complexity. For desktop, this is less true, we tested more than decade old devices which have proper WebGL browser support (even with all extensions and what not) but which are just too slow for the CPU side code.

 

On practically all platforms WebGL support is also just a software problem of users requiring a proper browser that supports WebGL, not a hardware problem (since it's based on ES 2.0), so if you plan to roll out your HTML5 app as a packaged application, as opposed to an actual web page that your players have to navigate to via the browser, you can just make sure to use a javascript runtime that supports WebGL in the background. This is much easier than convincing your users to upgrade their browsers (or even worse, switching to a different one) for your game. 

 

Also canvas performance CPU-wise is pretty bad. I have no idea why this is, but even on high end desktop PCs we struggled hard to draw more than ~600 small images per frame at 60 FPS, even if everything was packed into one or two atlases. This is one of the major reasons why we decided to go WebGL only for our next web game. 

 

Another thing to add, mobile & desktop browser WebGL support is at 92.6% globally as of February this year (probably 95%+ by now), according to http://webglstats.com/ , even just mobile devices have 90% coverage, but with the "roll out as stand alone application" approach you can probably savely put this in the 100% category. 

 

And last but not least, consider that supporting separate rendering paths is more complex than just going pure WebGL!

Edited by agleed

Share this post


Link to post
Share on other sites

I don't expect problem with browser support as won't deal with tech debt of supporting legacy browsers , I already exclude those insisting not to upgrade browsers.

 

My sole problem is that I can go with webGL only but considering how feature-poor (is this valid in English? :) ) this map is it can even be achieved with DOM as long as you have prerendered terrain. So it breaks heart not to include this due to small obstacle. If it was whole game or a classic HTML5 game I'd not mind but it's just part of it so it looks like asking webGL to play Travian.

 

And also I'd like to give "lite version" to those having webGL support theoretically but not practically (like my Lumia 920) And doubt map will push boundaries of canvas performance as it is basically sprites on terrain image.

 

But after your post, checked again for video card support and maybe I am a bit conservative. Most blacklisted cards are ancient. (Although I didn't have webGL support when using a netbook with GMA 950 which is ancient but not much) After checking how things are on mobile, a pure webGL approach might be smarter. Thanks for pointing out.

Share this post


Link to post
Share on other sites

 

GMA 950 which is ancient but not much
 

 

Mid-2006. That's a full decade, a veritable fossil in graphics. :)

 

 

Fair enough, still far better than S3 Virge :P

 

Seriously, I am convinced of making in webGL only and consider fallback only if it's trouble free.

Share this post


Link to post
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

Sign in to follow this