7

We have created an OpenGL application in C++ which visualizes some physical simulations. The basic application is contained within a DLL which is used by a simple GUI. It currently runs on a desktop PC, but we have the idea to turn it into a web service.

Since the simulations require dedicated hardware, the idea is that a user, through his/her browser can interact with our application as a service and this service then renders the result to an image (jpg or anything appropriate) that can then be displayed/updated in the browser.

My question: How can I "easily" turn a c++ application as described into a web-service that runs on some server so that I can approach it over the web? What kind of technologies/APIs should I look at? And are there any real-life examples that tackle a similar problem?

genpfault
  • 51,148
  • 11
  • 85
  • 139
user62146
  • 143
  • 1
  • 5
  • How often is the image meant to be updated? – Jim Buck May 19 '09 at 16:19
  • That would be after every user interaction. Slightly vague, but the typical scenario would be: a parameter change -> some time for simulation -> render and write to image -> update browser image. So no hard real-time needs in this case. – user62146 May 19 '09 at 16:41
  • How much users are you planning to support at the same time? Is it access for everyone, or only known set of users? do all users see what other users do - one instance of the application, or several? – Liran Orevi May 19 '09 at 16:42
  • It will be a one-on-one scenario. So no shared view between users. No simultaneous interaction. Perhaps we will try later on to run multiple simulation instances on the same machine at the same time, but for arguments sake let's start simple and say one simulation, one user. – user62146 May 19 '09 at 16:45
  • Did you find a solution to this problem? –  Oct 14 '09 at 12:02

8 Answers8

5

This is possible, but one major difficulty you'll have is trying to use OpenGL from a web service. You'll need to port this to do 100% offscreen rendering and work without a windowing context. That would be my first step, and it's not always a trivial one.

Also, it is very difficult to maintain and manage your opengl contexts from a webservice correctly, and the overhead involved can be quite painful. Depending on the number and types of renderings, you may run into some issues there.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
3

If you need it to scale up well CGI would probably be kind of slow & hacky.

There are some C++ web frameworks out there, see this question.

As far as the OpenGL goes, you'll probably need to use the frame buffer extension as Jay said. You could then render your image to a texture, and use use glGetTexImage() to grab the pixel data. From there just save into what ever image format you want with the accompanying library.

Community
  • 1
  • 1
Brian Gianforcaro
  • 26,564
  • 11
  • 58
  • 77
3

I had a similar project/question, that although it wasn't a web service, it required OpenGL rendering in a windows service. I had tons of problems getting it to work on Vista, although eventually it did work on XP with regular OpenGL.

I finally tried using Mesa, which I built to work as a private DLL for my service. It was a great decision because I could now actually step into the OpenGL calls and see where things were going wrong. It ran fine in software mode under the service, and while it wasn't hardware accelerated, it worked very well.

Community
  • 1
  • 1
kevin42
  • 2,108
  • 3
  • 22
  • 21
1

If your user-interaction needs are simple, I'd just look at CGI. It should be pretty easy to understand.

As far as getting the output of the OpenGL program, I'd take a look at the framebuffer extension. That should make it easy for you to render into memory, which could then be fed into a JPEG compressor.

Jay Kominek
  • 8,674
  • 1
  • 34
  • 51
1

I guess you already have access to some webserver, e.g. Apache or similar. In that case you could try out CppServ.

You just need to configure your webserver so it can communicate with CppServ. I'd then propose that you develop a servlet (check the documentation on the site) which in turn communicates with your already existing dll. Since the dll knows everything about OpenGL it should be no problem to create jpeg images etc.

rtn
  • 127,556
  • 20
  • 111
  • 121
1

How about using something like Flex to create a web-enabled 'control interface', with a server backend that streams the opengl rendering as video? Basically, you are redirecting keyboard/mouse input via the Flex app, and using it to display 'realtime' 3D activity using a standard movie component.

The devil's in the details, of course....

Dan
  • 974
  • 7
  • 11
0

This answer might sound very basic and elementary, have you tried this approach

  1. Send the vector data from the server to the client or vice versa (just co-ordinates and so on)

  2. Render it on the client side.

This means that the server is only doing the calculations and the numbers are passed to and fro.

I agree that is not a trivial method of trying to vectorize every object/model and texture, but is very fast since instead of heavy graphical images going across, only vector data is being sent across.

musefan
  • 47,875
  • 21
  • 135
  • 185
Kiran VVN
  • 1
0

You can try to use O3D API from google and don't do anysort of service, it would be much more simple.

user109074
  • 78
  • 4
  • 1
    Correct me if I'm wrong, but the problem with this is that everything would still run locally at the client-side, right? This is a "problem" because the simulations are quite heavy and we want to make them available to any user (maybe even mobile ones) on virtually any system with a browser. – user62146 May 22 '09 at 07:23
  • Are you sure that you will be able to run such heavy service in a cost efficient way? Cleint side solutions accessable from the browser would be much cheaper for you. – user109074 May 22 '09 at 17:07