I am looking for the best native library that is similar to three.js in its structure and simplicity but is also extensible enough to support glsl shaders.
Requirements:
Open Source or very well documented for possible extension/enhancement
Allows commercial derivatives/use
Can either be wrapped in a physics library or easily paired with one.
Fast enough to support modern game graphics.
OpenGL or Mantle based. (I don't want to be stuck with windows.)
Windows support
Supports a system similar to three.js local/world coordinate system.
Raycasting support for doing collision detection.
Huge Bonus:
Supports Linux and OSX as well as windows.
I am looking for the closest match to Three.js as possible that is written in C++ similar to three.cpp but has completed functionality and is less beta/alpha status.
Have you tried Magnum ?
http://mosra.cz/blog/download-magnum.php
Supported platforms
Graphics APIs:
OpenGL 2.1 through 4.4, core profile functionality and modern extensions
OpenGL ES 2.0, 3.0 and extensions to match desktop OpenGL functionality
WebGL 1.0 and extensions to match desktop OpenGL functionality
Platforms:
Linux and embedded Linux (natively using GLX/EGL and Xlib or through GLUT or SDL2 toolkit)
Windows (through GLUT or SDL2 toolkit)
OS X (through SDL2 toolkit, thanks to Miguel Martin)
Google Chrome (through Native Client, both newlib and glibc toolchains are supported)
HTML5/JavaScript (through Emscripten)
Threejs actually does support glsl shaders. You can use THREE.ShaderMaterial class to create your own shader then pass your vertexShader and fragmentShader to it.
Another option is to program directly in WebGL. ThreeJS is built on top of WebGL. The only reason why I decided to use ThreeJS was to avoid writing glsl shaders since WebGL doesn't have materials and forces you to write your own glsl shaders, so if that's what you want you could go directly to WebGL. WebGL is more low level than Threejs.
If you don't like javascript, then you could use JogAmp's Ardor3D which is in Java. It's a 3D scenegraph renderer just like Threejs but in Java.
All of the above options have super fast game quality rendering performance.
Related
I am developing a project using modern OpenGL through OpenTK. I want to use Gwen dot net GUI library in my project. Unfortunately, Gwen dot net uses old OpenGL for its widget rendering. I have tried merging both modern OpenGL and Gwen dot net and so far, have been unsuccessfull. Before I waste my time debugging my code, I would like to know, is it possible to merge both old OpenGL and modern OpenGL?
If you create a compatibility profile context, it should support all all legacy functionality. From OpenGL 4.3 compatibility spec, 1.2.4:
Older generations of graphics hardware were not programmable using shaders,
although they were configurable by setting state controlling specific details of their
operation. The compatibility profile of OpenGL continues to support the legacy
OpenGL commands developed for such fixed-function hardware, although they
are typically implemented by writing shaders which reproduce the operation of
such hardware. Fixed-function OpenGL commands and operations are described
as alternative interfaces following descriptions of the corresponding shader stages.
These days mixing old style and new style OpenGL is best avoided. On MS Windows and Linux you can, but weird stuff tends to happen.
For MacOS, Apple have declared that they're not going to support compatibility contexts at all, so you can't mix.
Since you're stuck with the GUI toolkit, I would try to isolate all your new style OpenGL code in a separate context and render to an offscreen target, then blit that to the main display.
OpenTK render for GWEN is a separate class. Just rewrite it modern way. There's no problem with that.
The simple direct media layer (SDL) provides a layer that allows the same code to compile into a consistent multiplatform application. However for 3D graphics SDL uses OpenGL. OpenGL has a known history for being inconsistent across platforms, even on just the PC platforms (Windows, Linux and Mac) so my question is does this still apply when using OpenGL with SDL? Or has SDL provided a solution for this inconsistency?
Does this still apply when using OpenGL with SDL?
Yes.
Or has SDL provided a solution for this inconsistency?
No. Closest they have is the 2D accelerated rendering API which wraps OpenGL/OpenGL ES/DirectX as necessary.
I decided to do some OpenGL programming on OSX. I created a small NSOpenGLView class in order for me to get an OpenGL view in cocoa.
From there my plan was to switch to C++ and create an object model to draw shapes. Having no interest in reinventing the wheel I decided to use glutWireSphere to represent my sphere class.
Interestingly XCode throws a deprecation warning for ~90% of all the glu and glut functions. Including the sphere function.
Is there an Apple library that provides primitives similar to Glut? Am I missing something? Is there a current HowTo for OpenGL programming on OSX (OpenGL >= 3.2)? I'm currently looking through the OpenGL Programming Guide for Mac but that doesn't seem to cover it. Googling it mostly returns IOS or old results.
Note: I don't want to force the compilation to 10.8. And I don't necessarily want to link external libraries like GLFW.
You might want to check out SceneKit if you can use 10.9+. It's a native Cocoa framework specifically designed for dealing with 3D rendering.
From the docs:
'Scene Kit is a 3D-rendering Objective-C framework that combines a
high-performance rendering engine with a high-level, descriptive API.
Scene Kit supports the import, manipulation, and rendering of 3D
assets without requiring the exact steps to render a scene the way
OpenGL does.'
In particular the SCNSphere class is what you'll be looking for.
And here's a nice scene kit intro by Big Nerd Ranch:
SceneKit in Mountain Lion
However, one thing to consider is that you'll end up with code that is not portable to other platforms as SceneKit is native to OS X (and eventually iOS). Frameworks like OpenGL, Ogre, Irrlicht on the other hand support many different desktop and mobile platforms.
Is there a browser engine that may use OpenGL as backend or adpater library to provide such? So that a web page can be rendered using a usual programmable pipeline of OpenGL.
I thought most browsers would use well known 2D frameworks that maybe would be provided with adapters by 3rd party, but just cant figure out if for example Webkit could work from a single mainstream 2D library.
Recent versions of WebKit will use the GPU accelerated graphics APIs provided by the OS if available. Direct2D on Windows and OpenVG on other systems if available. That being said it would be perfectly possible to implement a OpenGL backend to WebKit.
I suggest you look at current developments regarding Wayland on Linux, which will require some major changes in the way applications to their graphics business. There should be already substancial work on the WebKit-GTK+ bindings to make it use EGL created graphics surfaces. It is trivial to bind such EGL surfaces as OpenGL texture.
OpenGLES is not a 2D library, but I presume you meant frameworks that use OpenGLES for primarily 2D texturing. Chromium is one of the good examples of how OpenGL ES2 can be used for this, it accelerates canvas, CSS, and composition among other things using OpenGLES2.
http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
Until recently, the cairo-directfb backend for Webkit used to be quite popular, but now with every SOC having GLES2 support, things have changed. See for example below:
http://luorhino2006.wordpress.com/2010/04/02/build-webkit-over-pango-cairo-and-directfb-from-scratch/
I am working on a gaming framework of sorts, and am a newcomer to OpenGL. Most books seem to not give a terribly clear answer to this question, and I want to develop on my desktop using OpenGL, but execute the code in an OpenGL ES 2.0 environment. My question is twofold then:
If I target my framework for OpenGL on the desktop, will it just run without modification in an OpenGL ES 2.0 environment?
If not, then is there a good emulator out there, PC or Mac; is there a script that I can run that will convert my OpenGL code into OpenGL ES code, or flag things that won't work?
It's been about three years since I was last doing any ES work, so I may be out of date or simply remembering some stuff incorrectly.
No, targeting OpenGL for desktop does not equal targeting OpenGL ES, because ES is a subset. ES does not implement immediate mode functions (glBegin()/glEnd(), glVertex*(), ...) Vertex arrays are the main way of sending stuff into the pipeline.
Additionally, it depends on what profile you are targetting: at least in the Lite profile, ES does not need to implement floating point functions. Instead you get fixed point functions; think 32-bit integers where first 16 bits mean digits before decimal point, and the following 16 bits mean digits after the decimal point.
In other words, even simple code might be unportable if it uses floats (you'd have to replace calls to gl*f() functions with calls to gl*x() functions.
See how you might solve this problem in Trolltech's example (specifically the qtwidget.cpp file; it's Qt example, but still...). You'll see they make this call:
q_glClearColor(f2vt(0.1f), f2vt(0.1f), f2vt(0.2f), f2vt(1.0f));
This is meant to replace call to glClearColorf(). Additionally, they use macro f2vt() - meaning float to vertex type - which automagically converts the argument from float to the correct data type.
While I was developing some small demos three years ago for a company, I've had success working with PowerVR's SDK. It's for Visual C++ under Windows; I haven't tried it under Linux (no need since I was working on company PC).
A small update to reflect my recent experiences with ES. (June 7th 2011)
Today's platforms probably don't use the Lite profile, so you probably don't have to worry about fixed-point decimals
When porting your desktop code for mobile (e.g. iOS), quite probably you'll have to do primarily these, and not much else:
replace glBegin()/glEnd() with vertex arrays
replace some calls to functions such as glClearColor() with calls such as glClearColorf()
rewrite your windowing and input system
if targeting OpenGL ES 2.0 to get shader functionality, you'll now have to completely replace fixed-function pipeline's built in behavior with shaders - at least the basic ones that reimplement fixed-function pipeline
Really important: unless your mobile system is not memory-constrained, you really want to look into using texture compression for your graphics chip; for example, on iOS devices, you'll be uploading PVRTC-compressed data to the chip
In OpenGL ES 2.0, which is what new gadgets use, you also have to provide your own vertex and fragment shaders because the old fixed function pipeline is gone. This means having to do any shading calculations etc. yourself, things which would be quite complex, but you can find existing implementations on GLSL tutorials.
Still, as GLES is a subset of desktop OpenGL, it is possible to run the same program on both platforms.
I know of two projects to provide GL translation between desktop and ES:
glshim: Substantial fixed pipeline to 1.x support, basic ES 2.x support.
Regal: Anything to ES 2.x.
From my understanding OpenGL ES is a subset of OpenGL. I think if you refrain from using immediate mode stuff, like glBegin() and glEnd() you should be alright. I haven't done much with OpenGL in the past couple of months, but when I was working with ES 1.0 as long as I didn't use glBegin/glEnd all the code I had learned from the standard OpenGL worked.
I know the iPhone simulator runs OpenGL ES code. I'm not sure about the Android one.
Here is Windows emulator.
Option 3) You could use a library like Qt to handle your OpenGL code using their built in wrapper functions. This gives you the option of using one code base (or minimally different code bases) for OpenGL and building for most any platform you want. You wouldn't need to port it for each different platform you wanted to support. Qt can even choose the OpenGL context based on the functions that you use.