I am about to find a 3d engine which is capable of importing 3d models, detect their collisions and support joints. It's needed for an interactive animation and no platform is specified jet. I would prefer to code Javascript or AS3, but I think to be able to handle this with Java too.
Does Away3d support this? Is their a plain 3D collision detection framework I could use additionally to it? Which is the easiest Java Framework and which creates best Quality?
BTW.:
Proprietary Frameworks might also be an possibility, but I just do not any.
Greetings philipp
Away3D has Awayphysics library that is alchemy port of C++ engine and show very good performance. Away3D has clean readable source code and documentation + good set of example projects. It has 3ds max plugin that can export scene and generate code to render it. Support popular formats like 3ds, obj... and You can write importer plugin for own format. All so developers are pretty cool guys that answer questions on forum :)
For JavaScript the most popular engine is three.js Look what it can do.
General thoughts:
WebGL support isn't good at this time(sometimes it depends not only on user browser but all so on drivers) and You will need to deal with cross browser headache. Flash isn't supported on IOS and get kicked more and more from device browsers. But there is cross-platform adobe air for standalone apps.
Javascript, in my opinion, isn't good for writing such projects and its debugging can cause permanent brain damage. WebGL shader language is GLSL that has nice C-like syntax. Ordinary Flash shaders are written on assembler but You may try pixelbender3d. At this time Flash shaders more limited than WebGL(for example you can't fetch texture in vertex shader) but it's done to make Flash more compatible and it's not a problem for most cases. WebGL is tightly integrated with page.
If you want java WebGL and like pain try GWT 3D engines or gwt-elemental and there is tree-js port at early stage.
x3dom is declarative WebGL 3D engine with fallback to Flash it is ez but pretty limited and unstable.
Related
Is there a good GUI for VR? Scaleform is no longer supported. Coherent seems like an option. I just don't know how to integrate it if it is not natively supported by the engine. IMGUI seems like it is limited in the look that can be created by it. Are there any others?
Have you looked at Qt? It's very flexible and works on a variety of different platforms. QtQuick/QML in particular is pretty nice for VR interfaces.
Here is a video of a talk from Qt World Summit 2017 that does a pretty good job of summarizing the current state of things: https://www.youtube.com/watch?v=RtcmVbicZWw (Basically, the maintainers of Qt are working on a lot of cool VR-related things). I don't work for them and have only starting using Qt recently, but from what I've seen so far it works very well for this purpose.
In particular, take a look at QQuickRenderControl (http://doc.qt.io/qt-5/qquickrendercontrol.html). This class allows full control over rendering of QML content to a framebuffer. Right now I'm using it in the creation of SteamVR overlays.
I need to develop a small 3D game running on both Android and IOS mobile devices.
1- Should I implement EGL using within 3D logic or left it been implemented in Object-C or Java? which way should I go and why?
2- Should I use C or C++ for game logic? it is said C has better run time performance but harder to design due to it is not OOP C++ and vice versa. I have some experience with Java so I prefer OOP more.
Have you already considered to use a multiplatform library? For example:
libGDX
Especially if you are targeting for both platforms, such a library might be helpful.
I can only speak for Android a bit:
It actually makes no real difference, the Android API just provides calls for the same OpenGL C-functions, but still more comfortable, better supported and the recommended approach. Anyway there is Android NDK which allows to load original C/C++ code given the case you want to port some code from another platform (or develop for several platforms).
In my opinion the performance is mostly limited by the graphics (number of objects, size of textures etc.), usually not much by game logic, so Java would be more convenient.
We currently have a shared DirectX code base that renders our UI and is used in our PC side application and via an ActiveX in web pages.
I have written some WebGL demos and they perform great, no plugin mess and get rid of ancient ActiveX!
This obviously raises the problem of having a split code base for the PC application and the Web UI.
As WebGL is based on the OpenGL ES 2.0 specification would it be possible to have a standard code base and write a interpreter so that either:
-The WebGL code can be modified to compile as OpenGL
-OpenGL can be modified to work in a web page
The khronos specifications are new to me, so this is sort of speculative as I am peforming research at the moment.
Does anyone with more knowledge of 3D graphics and a better understanding of the coding syntax help me out?
One way is to have a PC app to enclose a WebGL-capable browser inside (together with a simple http server) to run the same rendering technique as the web App.
This will reduce the maintenance and development costs for both platforms.
the more i read about the different type of views/context/rendering backends, the more i get confused.
regarding to http://en.wikipedia.org/wiki/Quartz_%28graphics_layer%29
MacOSX offers Quartz (Extreme) as a render-backend which itself is part of Core Graphics.
in the Apple docs and in some books too they say that in any case somehow you use OpenGL (obviously since this operating system uses OpenGL to render all its UI).
i currently have an application that should capture real-time video from a camera (via QTKit which is based on Quicktime but is Cocoa) and i would like to further process the frames (via Core Image, GLSL shaders, etc.).
so far so good. now my question is - does it matter performancewise if you
a) draw the captured frame via Quartz and implicitely via OpenGL or
b) if you setup an OpenGL context and a DisplayLink and draw the buffered image explicitely via OpenGL?
what would be the advantages or disadvantages of going either way?
i've looked at the different examples (especially CoreImage101 and CoreVideo101) and documents from apple's developer pages but i can't see why they go (or have to go) that way?!?
and i really don't get where Core Video and Core Animation come into play?
does going way b) automatically mean i use Core Video? and with which way can i use Core Animation?
additional info:
http://developer.apple.com/leopard/overview/graphicsandmedia.html
http://theocacao.com/document.page/306
http://lists.apple.com/archives/quartz-dev/2007/Jun/msg00059.html
p.s.: btw, i am on Leopard, so no QuicktimeX confusion yet :)
Generally speaking OpenGL just gives you more flexibility than the higher level APIs. If the higher level APIs do not offer a feature you need then it is very likely that you will need to drop down to the OpenGL layer.
If they do offer everything you need then you should comparable speed. Perhaps a small (almost negligible) degradation given the Objective-C overhead.
I am new to opengl and using C#,opentk for development. My Application is very light weight (just 2d graphics) and i am planning to use software rendering when hardware rendering is not available.
How do i make sure software rendering works on all computers ? (when hardware rendering is not available.)
Should i distribute Software rendering libraries like Mesa, myself. or it will already available on all (Windows) OS ?
in other words, opengl32.dll is always available on all modern windows OS ( > XP SP2 ) or should i distribute that also ?
( My Application is very simple (simple 2d graphics) as of now. I selected opengl instead of GDI+/WPF because, i may extend it to 3D in future. )
OpenGL is a system library. You should not distribute it with your application. Especially on Unix/Linux systems, where it should be installed using the distribution's package manager.
Since opengl32.dll is included in Windows, it falls back to Software Rendering automatically if the pixel format you chose in your application isn't hardware accelerated by the graphics driver.
I tried leveraging OpenTk as well, but in itself creates a dependency and - particularly as a newbie - doesn't really do anything but confuse learning OpenGL versus learning someone else's interpretation of the framework.
OpenGL is - as the other answerer suggested - a system library. With this, it's a functions contained in a C DLL which you import through the API.
OpenTK imports these functions for you, that's the only real benefit it adds, but in doing so, many of the types are reinterpreted as are the function calls as per the author of OpenTK.
This creates an additional learning curve - as most of the internet references you're going to find are going to be OpenGL - so not only will you be struggling with understanding OpenGL - which isn't easy - but you're also going to be dealing with OpenTK interpretations of the OpenGL standards.
Now keep in mind that MANY open source projects such as OpenTK start as open source until they get sufficient enough user base, when they convert over to a for profit model. So let's say you learn and become dependent on OpenTK, well if/when they switch to a for profit model and you're tapped on cash, you are SOL (Shit outta luck). Or you have to pay their price.
What I did was - I took the source for API mapping for OpenTK's OpenGL mapping and renamed everything as per my tastes. it's a bit of work, but it's worth the labor and it helped me get to understand OpenGL.
As for distribution. I have absolutely no external dependencies I rely on other than the OpenGL DLL which should already be on the system.
ALL the DLLs you need for OpenGl will ALREADY be preinstalled on any windows OS you're dealing with. I can't speak for other OS flavors, but I suspect this may be the case.
On a final note: OpenGL handles 'toggling between software and hardware rendering' innately. So libraries like MESA and OpenTK add VERY little value at HIGH potential costs.
What are those costs?
1) Redistributable packaging and licensing. They still come with a license and most license are subject to change at any time.
2) Conversion from open source or free distribution to a for profit model.
Invest in yourself. OpenGL documentation is vast and at times confusing, and my advice is to avoid the knee jerk temptation to 'take the easy' path versus the leverage other's models - for one simple reason.
I know you're using this for a 2d application. And even if you're using Orthogonal view, the fact of the matter is you're learning OpenGL with is a patterned with 3d in mind. So give yourself the gift up front of teaching yourself because there really is no 'easy path' to understanding 3d - and thus no real value add to the external dependencies you're leaning towards using.
One thing to keep in mind: Modeling. IF/when you switch to 3d modeling, doing vertex creation through hand coding in opengl is a bitch. I use Blender to create my obj models in and read those into my own c# application which reads in the 3d models and lets me manipulate them from there.
I HAD been using C++, which sure is faster, but once I converted the APIs to c# code and started managing my own memory leveraging the garbage collection model, it became SO much easier than having to learn someone else's library.
Dont use redistributeables. And leverage the code from OpenTK, with modification, but don't include OpenTK as a redistributeable.
That's my advice.