I've been mucking around with this idea to render models with openGL within a webserver, and return the image as a jpeg back to the browser. The idea for the project is for a better opensource GIS mapserver. What I want to end up with is a GIS mapserver that uses Oracle Spatial for data storage, hardware opengl renders with an AOLserver c module, and returns the image back to the browser. There is no reason why it would have to be used only for GIS data... any vector data large or small would work just as well. (models, maps, cad... whatever) I've gotten this much to work: ¤ basic AOLServer mod opengl rendering a demo scene ¤ linux/GLX based and running on a voodoo/banshee card ¤ creates the jpeg on the fly, and dumps it back down the conn (no tmp file) ¤ fully multithreaded code (AOLserver is fully multithreaded) I have the demo running @ http://www.caferegina.com:8000 Is there anyone out there interested in this project? Edited by - rohar on 11/2/00 4:41:11 PM

The URL you gave times out. I''d love to see a demo of this though. It doesn''t seem scalable from an architectural point of view. The Webserver must serve 100s or thousands of simultaneous http requests. Most sites have problems with dynamic html never mind openGL images, and break it off into an app server. They also cache TONS of stuff. Unless you have a decent caching strategy this won''t scale. Instead of dumping it down the conn you should tag it with the input parameters that generated it and then save it to disk on the websever. I''d also architect it as an NSAPI/ISAPI plugin that brokers the request out to another machine to take the load of the webserver CPU. At least that way you can add machines to scale transactions.

http://www.CornflakeZone.com
//-- Modelling and animation in every dimension --//

Thanks for your input.

Caching doesn''t work very well when your parameters are floats, the odds of creating exactly the same image twice start to get pretty small.

That is the whole reason I am trying to do a real-time rendered approach, and not writing a tmp file is a performance thing.

There is a great document on scalability vs reliability here.

Caching the rendered images is probably something I would add as an API option, but it will only work if the data isn''t dynamic, or if your interface didn''t allow free movement. If your parameters have a wide variation, or if the data isn''t static, even if the parameters are the same, you couldn''t be sure the data hasn''t changed, you would have to do just as much work as just re-rendering it.

If the data is static and movement is limited, you could just pre-render a ton of images (hard drives are cheap) and this whole project doesn''t have much value.

The demo code will kick out almost 500 jpegs/minute on my lan with a pIII450 with a voodoo banshee. That would do for alot of applications. What I am going for is a fast and stable solution that would work for most sites on a mid-range machine. A pro video card would go along way in a scalable web service, or several cards.

I am only interested in the project as a platform independent open-source thing. AOLserver is open-source, multithreaded and probably about the best C code I have ever seen. It is ported to most of the platforms opengl is on. I would imagine an SGI or sparc box with a couple of pro cards would scale pretty well.

Take another shot at the link above. Other people have been using it ok, but it is on a cable modem, which is kinda flaky sometimes.

Sorry for my last post, I didn''t mean to shoot down your idea. In my real job I design and build large sites which need to scale to thousands of transactions a second, not minute. They also have to continue scaling. If you''re shooting at mid-range sites I think you''ll still want to revisit the architecture as it will bottom out at some point. Why not move the processing to the browser like flash? I''m just very wary of anything in the web world that centralises processing. Good luck with it.
fs

http://www.CornflakeZone.com
//-- Modelling and animation in every dimension --//

The java client idea is good. They use a thing like that @ www.scorecard.org. That is a site by the Environmental Defense Fund. It uses an open source java based map server. The java client does a few neat tricks.
I kinda favour not having anything to support running on the client machines.

fshana: Your comments were really appreciated and the scalability thing IS the main issue. It is a tough problem to solve with dynamic requests based on float parameters. IMO, the best way to go is a central datastore (oracle) and a peer based opengl->jpeg server system. Letting Oracle handle the persistance across machines is a proven reliable and scalable method. The main application would load balance the image servers by writing out the image tags in a round robin fashion. That would mean that it could return multiple images from more than 1 server on a single page. It could also do a quick alive testing on the image machines to make sure they are up the instant before it pukes out the HTML. That would give the reliability and serviceability (you could take down any of the image servers, at any time).

The reason for my original post was to find if there were people interested in working on a project like this. Whatever I do will be open-sourced; I don''t have the resources to do this on my own.
Please try not to take offense to my response to your comments... I asked for your comments.