I am creating a software for calculating gearbox parts using Swing and OpenGL (with JOGL).
With this software the calculated parts are shown in 3D. The following picture shows an example part:
At first the geometry is specified/calculated (tip/root Diameter, width, number of teeth...) and out of this data the 3D-part is created. This example part is made with JOGL-Code because it's easy to use for me and can be integrated in a Swing-GUI.
Now a played around a bit with JavaFX Application GUI's and decided to continue making my software in JavaFX because it offers everything i need, looks much better and so on. The problem is I can't use my JOGL-OpenGL graphics.
So here are the possibilities for me:
Search for a way to integrate OpenGL-graphics in a JavaFX-Application - but I googled a bit and this seems to be quite difficult and the possible solutions seem to be very slow.
Use JavaFX integrated 3D-graphics (TriangleMesh) - but this is difficult to understand and I can't find good examples to learn it.
Any other solution?
Can you please help me finding a good solution? What would you do? My favorite would be to continue using OpenGL, but is there any good solution for this yet?
If you are looking for some JavaFX 3D resources that may help you decide whether its already mature or not, these are available, among others:
3DViewer here from the OpenFJX project.
InteractiveMesh importers and browser.
F(X)yz, a new JavaFX 3D library that provides additional primitives, composite objects, controls and data visualizations that the base JavaFX 8 3D packages do not have.
Multimodel3DFX, repository contains the code for the example shown on the article "Building Castles in the Sky. Using JavaFX 3D to model historical treasures" published in Oracle Java Magazine, issue from November/Dicember 2014.
Using a PolyLine3D from F(X)yz and the Multimodel3DFX plaftorm I was able to extrude a 2D polyline of a spur gear, so you can see how it's rendered in a JavaFX 3D subscene:
These are also mathematical 3D models generated using the F(X)yz library, all of them based on TriangleMesh.
As you can see, JavaFX 3D API, with its pros and cons, can be easily extended to achieve complex tasks.
Related
We want to embed a 3D CAD viewer into our web-based collaboration platform. It would work similar to the one offered by Opencascade. You can see it here.
We do not charge for the use of our platform and we would prefer an open source option if it is available (Opencascade viewer is not open source).
Does Autodesk Forge have a similar offering?
Thanks!
CAD viewer solution for a WEB can be split into several pieces:
On-server converter of CAD model.
Conversion of CAD file into intermediate format. You might need a lot of Data Connectors in case if you need supporting wide range of CAD formats, or restrict functionality to import vendor-neutral formats like STEP.
Generation of Web-friendly triangulation-based 3D model. This step might include model simplification in case if you have to deal with large models.
Server backend implementing business logic and backend for 3D viewer. The complexity of 3D Viewer backend depends on functionality provided with it and ability of viewer to handle extra-large models. In simplest case, this might be just a file server providing 3D model in format like glTF.
Client part, e.g. HTML+JavaScript code for displaying 3D model using WebGL, as well as GUI and application-specific logic. The viewer might just display 3D model (in which case it is barely distinguishable from non-CAD viewers), or give many features like Shaded and Wireframe (not just mesh edges) modes, picking sub-parts, Clipping Boxes, clipping with capping, annotations, dimensions, explode view, HLR view, a bunch of them!
Although it is technically possible loading some small CAD models directly in the Browser, in general this task is expected to reside on server to improve user experience and give some protection to intellectual properties (of CAD models). The converter may be based on Open CASCADE Technology, which is an open source framework, in case if STEP/IGES input file formats are enough (output could be your custom file format or glTF 2.0, for instance). But in case of native CAD formats support (like CATIA and others) you will unlikely find any free open-source libraries.
The Web viewer itself relies on WebGL and normally can be based on any traditional JavaScript-based library like Three.js (or existing 3D Viewer on top), or may rely on C++-based engine (again, Open CASCADE Technology can be build as WebAssembly module). WebAssembly-based viewer may give some performance benefits and it is more friendly to C++ developers (but apparently - less friendly to JavaScript developers). There is a hidden issue, though, as many open-source C++ libraries commonly have LGPL license - pretty good for desktop, but might have legality issues in case of a Web application. In contrast, WEB-based libraries are normally more proprietary-friendly with permissible licenses ignoring open-source software ideas put into licenses like (L)GPL.
In general, 3D CAD Viewer definition is very wide, and requirements list in your question are very basic and unclear - just to embed 3D Viewer in your WEB application. You may write your own Web Viewer based on open source components, or consider commercial options already implementing features you are looking for, and aware of / providing some solutions for handling tricky problems.
Looks like Forge Viewer fits the bill perfectly and covers most of the features available with the demo ;)
You may experience/preview Viewer following this link using a model of your own here and follow here to build up a MVP here...
For the features that are not readily/built-in out of the box Viewer is highly extensible and offers API making it pretty straight forward to develop extensions following here and also the blogs/tutorials available here.
What is the better framework for development Windows Store application?
I have used http://metroprism.codeplex.com/ but now I want to use Caliburn.Micro or MVVM light for another project.
I have looked through several application examples for these frameworks but they were not complicated enough for me to estimate usage in bigger projects.
These two ones are completely documented but the problem I think is that documentation for winrt mixed with WP7, Silverlight and WPF and I doubt a bit in supporting all features and practices of using exactly for Windows Store application.
Could you give me advice what is the better one? Or what are the good practices in development for Winrt with modularity supporting like in Prism for WPF and Silverlight.
Thanks.
MVVM Light and Caliburn.Micro basically do the same thing but they do it using opposing "philosophies of development" in MVVM.
MVVM Light is a "view first" approach. In this approach the ViewModel is instantiated in by the View. In MVVM Light this is done via something called the ViewModelLocator, a static class that binds a public property directly to the DataContext of the View.
Caliburn.Micro is a "viewmodel first" approach. Here you find that the viewmodel and view are created by an IOC mechanism that binds the two together. You navigate from viewmodel to viewmodel, with the views being generated in response to the navigation to a ViewModel.
They both have different features:
MVVM Light has a really nice messaging system for allowing view models to communicate with each other in a loosely-coupled way.
MVVM Light has a really simple mechanism for injecting design-time data into your views. Basically it swaps out your runtime services with design-time services that feed data to your viewmodels and, in turn your view. This makes design time data really easy to use.
Caliburn.Micro has an amazing data-binding setup, where it handles most of your databinding scaffolding for you. Basically, it maps the names of methods and properties to the names of controls in the view and autowires them. This saves lots of code and is a really, really nice feature.
Caliburn.Micro uses a "Convention over Configuration" mechanism to map views to viewmodels. MainView maps to MainViewModel, etc. This means you've got no configuration, you just need to make sure that you've got your naming conventions sorted out.
I've used both frameworks (Caliburn.Micro for WP7 and MVVM Light for Windows 8 Store Apps) and like them both for different reasons. MVVM Light is easier to start using but Caliburn.Micro is probably more powerful. I've found them both more than adequate for writing moderately complex applications quickly.
Caliburn.Micro gives you clean XAML at the cost of some magic. MVVM Light is a clean and simple framework that is easy to understand and works well. Prism seems to be a bit heavier than MVVM Light and more business app oriented - it does more than just MVVM. There are many things to consider. Choosing what you already know will let you focus on adding features, but learning a new framework can certainly be a good learning experience helpful in future choices - so you could pick something you haven't used before if you want to learn. You could also write your own framework and only include what you need. I usually go somewhere between roll your own and MVVM Light because that is what I know, though if I were to build a bigger enterprise app - Prism might be better suited for the task. I haven't used Caliburn.Micro because the novelty of different MVVM approaches wore off for me and I just want to create apps. With WinRT a roll-your-own-framework approach is easier than with any platform before because the basic project templates already give you some foundations as I wrote in my Minimalistic MVVM blog post. I would recommend that approach if you already tried MVVM and want to use only the pieces you need - the framework will grow with your app. You can just grab pieces of code from other frameworks if you need them or write your own implementations of the patterns you need.
To summarize
If you want to learn - try something you haven't tried before or write your own framework
If you want to create an app quickly and it is not a huge app - use what you know or go minimalistic and don't use anything but what you get from the templates
If you are building a big app with lots of features - consider Prism or rather first think whether Windows Store is the right target platform for you since it seems to be focusing more on simple in and out tablet apps
I am currently working on a 3D engine in AS3, I have designed it for the new upcoming Molehill API but I also want to render to the current AS3 graphics API. I thought that I would write a stack based implementation to render to the target DisplayObject. I then realised that I could essentially create an OpenGL API style interface to abstract my 3D engine from the actual rasterizing processes. (Just like any 3D engine built on OpenGL) This would also then allow other 3D engines to make use of the code as with any other imported library. Obviously there would be functionality handling the viewport, matrix stack etc, but a simple example my be:
AS3GL.begin( AS3GL.GL_TRIANGLES );
AS3GL.color3f(1,0,0);
AS3GL.vertex2f(0,0);
AS3GL.color3f(0,1,0);
AS3GL.vertex2f(.5,0);
AS3GL.color3f(0,0,1);
AS3GL.vertex2f(.5,.5);
AS3GL.end();
I wondered if anything like this already exists for AS3 that I could use, or if anyone has any detailed information about the inner state systems and/or stack implementations of OpenGL.
Adobe Mole here. What you want to do is very possible. You should start with reading old OpenGL specs. However please consider what you really want to do and why. As an educational exercise it is great to map tech from the 70s to a modern API. If you want to do a useful library or learn modern 3d, this is a dead end. One great thing about the Molehill API is that it does the right balance between a scripting language and GPUs: Use script to batch big chunks of triangle drawing. Doing multiple calls for every single vertex defeats that model.
I have decided to start this as a project myself, if anyone wishes to contribute please contact me. I have registered the site AS3GL.com and setup a google code repo ready for this. If anyone is able to send info about the stacks and inner workings of OpenGL, I would appreciate any info.
[EDIT]
This library became discontinued, but here is the GitHub repo for reference 'dev branch' https://github.com/Zest3D/as3gl/tree/dev
This question is directed to anyone out there that is just starting in hobby game development. The first thing that comes to ones mind is:
Which language/framework should I use?
List of solutions:
Adobe Flash -> done
Allegro
Apocalyx
Blender Game Engine
Blitz3D
Devkit Pro
Game Maker
Gosu
IndieLib
jMonkey Engine -> done
Microsoft Silverlight
Microsoft XNA -> done
Multimedia Fusion / Games Factory
OGRE -> done
pygame -> done
pyglet -> done
RubygGame
SDL -> done
SFML
Torque 3D
Unity 3D
Custom -> done
Answer template:
Framework Name (Linked)
Pros:
Pro1
Pro2
...
Cons:
Con1
Con2
...
Microsoft XNA Game Studio
Pros:
Uses .NET languages; managed memory, ease of the Visual Studio environment, etc.
Good mix of high-level and low-level
Supports both 2D and 3D very well
Is proven; look at the Xbox Live Arcade, all of those games are made with XNA
Games can be easily run on a networked Xbox
Cons:
Uses .NET languages; can't use Java, C++, etc.
Not too many resources (i.e. books) out yet, though it is easy to learn and use so that may not be an issue
Windows-only. Mono (on Linux) doesn't support XNA at all.
XNA 3.0 was released less than a year after 2.0, and now we're at 3.1; frequent changes like these can hinder documentation, i.e. books get outdated quickly and many things break when upgrading a 2.0 game to a 3.0 game.
As of 2014, discontinued.
If you have the time, do it all yourself. It's worth the experience and you'll learn a lot, instead of how to work with framework X . ;^)
Pros
Full Control
Strong Learning Experience
Consistent code between game engine and program
Tends to be well-suited towards the application it is applied towards.
Supports any language/environment
Cons
High difficulty
No online documentation
Generally, less generic. Harder to apply to other games.
Harder for other people to use.
Probably buggier than more popular frameworks.
Not well-tested.
Harder to get help.
jMonkeyEngine
Pros
Uses Java; managed memory, highly supported in many mature IDE's (Eclipse, NetBeans, etc.), highly portable
Good mix and high-level and low-level
Modern 3D scenegraph
Built atop LWJGL, a very mature and well-working game library
Very lightweight; doesn't add very much overhead
Built in 3D model loading in a variety of formats.
Built in modern node-based 3D scenegraph.
Easy to use.
Open source; constantly evolving and improving.
Includes culling, collision checking, etc.
Has the option to save and read its own ultra-compact, ultra-fast binary model format.
Full list.
Cons
Uses Java, so compiles JIT and can therefore be a bit slower than C++ and other options.
Hasn't been used in many commercial apps (and therefore not as "proven").
Has no attached editor of any kind, everything must be done in pure code.
Difficult to do 2D games (for that you could try Slick).
pygame
Pros:
Easy to get started and create something visible.
Cross-platform.
Lots of open source games available to inspect the source.
Python language's pros (flexibility, dynamic typing, strings/arrays/tuples, etc.).
Cons:
Performance-wise does not scale to very large games (which hobby game development rarely is).
Mostly suited for 2D, although 3D is possible.
Difficult to distribute as closed source.
Also SDL could be inserted as pros and/or cons.
OGRE (Object-Oriented Graphics Engine)
Pros:
Tons of 3D features
Cross-platform, uses DirectX or OpenGL
Plugin architecture for even more features
Does not try to be an everything-engine, only a graphics engine (doesn't even try to handle input, as many graphics libraries tend to do)
Cons:
Uses the Singleton pattern
Very hard to do 2D or primitive rendering (individual polygons, lines, etc)
Tons of code makes the learning curve quite steep
pyglet
Pros:
Low difficulty
Cross-platform
OpenGL accelerated graphics by default
Further OpenGL graphical enhancements easy to add
Python language
Cons:
Less well-known than pygame
Game 'loop' is a bit unconventional
OpenGL knowledge required for advanced graphics and to maximise performance
SDL
Pros
SDL officially supports Windows, Mac OS X, Linux, iOS, and Android
It is used by video playback software, emulators, and popular games including Valve's award winning catalog and many Humble Bundle games.
Open source
SDL is written in C, works natively with C++, and there are bindings available for several other languages, including C# and Python.
Cons
No special IDE like Unity
A bit low-level
The pros of any framework (gaming, web, etc.) is that they remove the unnecessary boilerplate code you'd have to normally write.
The cons often come up later on, once you want to go beyond the capabilities of the framework it can become very difficult. With many of the more complex frameworks, extending their functionality to make it do something it wasn't designed to will results in you having to write a lot of your own boilerplate code.
just starting in hobby game development
You should program a few games before attempting your own framework, otherwise you don't know what to put in it and how to write it. You'll end up endlessly rewriting it to "get it right", when really there are lots of good (and bad) ways of doing it, depending on what it is used for.
"Frameworks" can also be a pain, as they offer a partial solution to a problem. E.g. you just extend a few classes and boom, you have a game. But if your game doesn't suit the framework design you just end up fighting with it and hacking it. The "toolbox" approach tends to be a better approach as it just supplied functionality without forcing you too much into how you should use it. E.g. the standard C libraries are are toolbox and don't force you to structure your code in a certain way.
To start off with you have to ask yourself:
what sort of games you'd like to write.
what you'd like to develop for?
Web browser?
Facebook?
PC?
PC and Mac? i.e. cross platform
Console?
iPhone and iPad?
which language you'd like to use (but this may be set by the platform you chose)
The learning curve for writing games can be quite steep as you might have to learn:
how to program in a new language
how a new API works
how to do the graphics and sound
how to debug it
perhaps how to hook it into other system
Don't be put off it this sounds like a lot of work! The key to writing good games is sticking it out and having the determination to carry on and finish. Have you seen the film, Indie?
My advice:
Start simple - There is a lot to learn, if you take on too much to start with you will be scared off and think it is to hard. So...
Easy language - You'll hear lots of people ranting on the internet about how great certain languages are. Well, they all have their pros and cons. Some are easier to learn that others. E.g. Python or Lua are quite easy to learn. They are scripting languages, which are a lot more forgiving and less complicated to games together with. They don't have things like pointers, memory allocation, etc to worry about.
Python tutorial.
Lua has a tutorial (which I wrote!)
Just make a game! - You'll hear other people talking about patterns and singletons and data driven design etc. None of that matters when you start out. You aren't trying to impress anyone with your code. People will judge you on the end result not the code! Trust me, some of the best games you've played on console etc have terrible code!
Use a small, well maintained library. I'll make it easy, there are other choices, but:
if you want to choose Python (a good choice!) use pygame. Use Eclipse (for Java Dev) with PyDev. Magic and free!
if you want to use Lua (a good choice!) use Love
Look for other game examples - Pygame has tons of examples and games using it. Check the license and if you are allowed, just rip the code. Patch, splice, but put a comment about where you got the code, it is polite, and may be necessary according to the license. Don't ignore the licensing.
Look at Ludum Dare. Tons of great examples and source code to see how it is done quickly.
Then once you have made a few games consider the more complicated libraries and languages. Then you can ask more specific questions about how to solve certain problems. Have fun!
Flash
Flash is a great tool for those who have limited programming or art experience, but want to start cranking out a game.
Pros:
Symbols make graphical creation and manipulation very easy
Symbols have built-in bounding boxes; bounding boxes have built-in collision detection
Ports easily to web
Built-in layers and display architecture make displaying content simple
Lots of support, documentation, libraries
Vector art is easy to create
Cons:
Relatively slow
No method or operator overloading
Requires a purchase, either Creative Cloud or buying Flash outright
Pixel art must be ported in, which can be aggravating
I highly recommend flash if you have access to it, its one of the programs I use most often.
Pro's for XNA in my opinion are that XNA apps can run on Xbox360 in addition to PC, and you can pick your favorite language from anything supported by the .NET Framework - which is quite many.
i've been making web app's and working with various server side language like php, ruby, perl for a while now. I've always been curious about game development, it's actually what I set out to do but I ended up in web development. I am trying to transition in to GD, but I cannot help see games from a web development POV.
GD = Game Development
WD = Web Development
Technical Questions.
How do you design UI in games? in WD you have CSS, and need minimal graphics to create a quick menu. are there similar tools or concepts in GD ?
How do you deal with storing data ? Do you use flat text files? Or is there something like MySQL or sqlite that you use to store information about objects, users, and etc ?
What game engines is commonly used ? Are there any that use scripting languages ? I only know VB and basic understanding of C.
With the proliferation of Iphone and Android, is J2ME being phased out for mobile phones ?
open 3D web is coming. What is your thoughts on having 3d applications running natively from your browser ?
What tools make it easy for creating 3D objects, levels, game environment, and animating characters and so on ?
Where can I find out more about how server/client, client/client, and MMORPG networking works ?
Where can I get or find generic or commonly used game flows ? for multiplayer ?
How do you deal with physics? Is there freely available algorithm or library that you can use ?
How are real time cutscenes made in games ?
Market Questions.
Which market should you enter? Mobile, iphone, wii, PSP, DS, android , ps3, PC etc.
Shouldn't you always enter mobile market, as it is easy to make small games on your own yet sell a lot ? Are there any resources where i can find more about each markets ?
What is your thought on Steam content distribution ? Is it the distribution model of the future ? Whats wrong with the traditional publisher/distributor model ? How does the traditional model work exactly ?
How big is the web games market? ex) Flash games.
How is game development different from any other software development or web development ?
I have a lot more....but those are the ones that I have been thinking about lately.
Thank you very much for reading !
UI Development
Depends on the game- is it animated, or a board-style game? Generally, UI assets are created as images, sprites, or storyboards.
Data
Again, depends on the game type. Realtime games need FAST access, so you want to store your data in a local database and cache it as much as possible. Local file-based databases tend to be the norm, either custom or off-the-shelf, such as SQLLite.
Engines
There are tons of engines out there for 3D, board, etc. Popcap has made their C++ game engine open source. Others include Unity, Ogre3D...
J2ME
I wouldn't target this platform for games.
Don't know much about "Open 3D Web" but it sounds very browser-dependent, so mileage may vary across browsers.
You can play with 3D with Google Sketchup and Caligari Truespace. Truespace was bought by Microsoft and made free.
Again, tons of engines out there for networking. Example: Microsoft's XNA framework has some networking bits you can leverage.
Not sure what you mean there.
There are physics engines built into some of the gaming engines I've mentioned, and external ones you can use.
Once upon a time, realtime custscenes were pre-rendered with 3D Studio Max or Maya. These days in-game rendering is often good enough for cutscenes: look at the latest Halo 3:ODST game. All cutscenes use the in-game engine.
Market
I looked into game development earlier this year. Casual games look to me like a growth industry- high volume, relatively low development cost. Big Fish Games for the PC is a good example there- they publish a few titles and resell most.
I think mobile game development is a huge potential market but the barriers to entry are high because it will be a crowded space. iPhone games are the 800lb gorilla but Android is coming up. PSP and others have a limited audience and are notoriously difficult.
The most important thing I learned in my research is that game development is a labor of love. It's hugely multi-disciplinary: you need programming, art, concept, production. It's more like making a movie than anything else. It's also rough to make a profit because of all that overhead. If you want to get into it, I recommend joining a game developer to learn the business. Once you have experience you can carry it forward to larger gigs at larger publishers. Eventually you can get to work on a major AAA title, after which you can really write your own ticket.
I'll stick to answering the technical questions:
1 - UIs are usually completely bespoke, with nothing resembling a standard in the same way that HTML/CSS is a web development standard. Some people use ScaleForm which is based on Flash but that is by no means common.
2 - Data is often stored in flat files - rarely text, more commonly binary. Again, these are almost always completely bespoke formats. Sometimes they are aggregated into archive files which use the zip format or something similar however. Occasionally, some programs might use sqlite, and online games often use SQL databases.
3 -There are many game engines used, although the definition of 'common' is vague. There are well-known ones like the Unreal or Source engines, down to lesser known ones like Panda3D or Torque. Some of these are heavily focused on 3D and leave much of the rest of the functionality to other packages (or the game developer themselves). Most are able to be used with scripting languages, or come with one built-in. (eg. UnrealScript).
4 - J2ME - couldn't say, that's not the sector I work in.
5 - 3D web will be interesting when it's ready, but cutting edge games currently require gigabytes of client-side data. Running the application in the browser doesn't get around that download, so it's not a great benefit. Nor is it likely to be as high performing as a dedicated 3D game renderer for quite some time. So while it opens many doors, it doesn't significantly change the state of play for gaming just yet.
6 - 3D art assets are usually made with 3D Studio Max or Maya, although there are several other related tools.
7 - MMORPG networking firstly requires understanding of basic networking (ie. strip away all the HTTP fluff and get right down to the socket level). Start with Beej, work up. From there, you're best off reading talks given at conferences and reading the Massively Multiplayer Game Development books, coupling that with anything you can find on traditional game networking. 2 good starting points are the Source Multiplayer Networking docs, and Gaffer's Networking for Games Programmers. Don't expect to understand everything the first time you read it, either. And bear in mind this is a field with ongoing research and the problems are far from solved yet. And that it's also a field where "if you have to ask, you can't do it yet". Emphasis on yet.
8 - I don't know what you mean by game flow - it's not a term I've heard used before.
9 - There are several physics libraries available, including Havok, ODE, Bullet, PhysX, Box2D, etc. Some are free, some are not. You can also write your own physics for simple games, as it's not all that hard, and indeed that is what everybody did until relatively recently.
10 - Real time cutscenes are typically either pre-animated in something like 3D Studio Max, or scripted to run within the game engine.
It depends very much on the platform you are developing for. some game engines, or platforms, have built in platform specific means of creating UI systems. An example is developing for the 360 where there is a proprietary UI system provided with the SDK tools.
However, systems like these tie you to a particular platform and this can be undesirable.
Another alternative is cross platform libraries like Scaleform, which provide game-side libraries for displaying UI elements, and a common way of editing and creating UI systems across different platforms.
The complexity of UIs in videogames varies wildly. Look at something like Peggle, compared to something like Codemaster's Dirt or EA's Dead Space. Each system is therefore implemented differently.
Some use 3D packages and the standard game engine to animate and render UIs. Others implement Flash. Others roll their own custom solutions. There's no easy choice or a standard like CSS I'm afraid!
Hope this helps,
-Tom