Amazing work Goran. LibGDX is a great engine and I can see it doing justice to blender scenes.
I’d like to get involved, here are my qualifications:
I wrote a blender scene exporter addon for a libGDX game I’m working on. It’s pretty specific for the game, my model formats target 4 hard coded shaders, but I got a good taste of the basic concepts. (vertex array formats, scale/rotation/translation, instancing objects, texture coords, etc.)
Hmm… That’s not too good to hear. The thing is, once you manage to create a game that can only run at, say 30fps on modern phones, the game will be sluggish and annoying to play… Even more so than just the frame rate lag.
Can you set bullet’s update time to a changeable variable from within bdx, please (default 60)? Getting and setting delta time for logic in java is easy enough, so applying that would be really easy.
This project would undoubtedly benefit from your help, in whatever capacity you can offer.
I also spend a good portion of my time in FP land. I lean more toward strongly typed Haskell derivatives, like Elm, but I know that Clojure is just as powerful, as it builds on the same fundamental principles.
I would much rather write Clojure than Java, but before I could, I would need to figure out how to replace the libgdx HTML5 export pipeline, with one that relies on ClojureScript infrastructure; As far as I understand, that would be the only way to export libgdx Clojure projects to the Web … Or maybe there’s a way to decompile the bytecode that was generated by the Clojure compiler, to GWT compatible Java code?
I don’t know enough about Clojure + libgdx to speculate on the overall viability of those approaches, but I know that the Web is an increasingly important platform, and that I would be willing to suffer writing Java (as I do now), if that was the only way to have games in the browser.
Anyway, I’ll definitelly drop you a line when I get BDX (v0.1) on github.
Thank you!
Yes. As an open source project, BDX will seek out generally useful contributions.
The definition of “particle” is not tied to details of implementation. If used as such, a “textured object spawned to face the camera” is indeed a particle, as is anything else that can serve the same role.
Discussion is fine, but I would agree that it’s a low priority issue, at this point in development.
You should aim to make games that can easily hit 60 fps on relatively modern devices. In some cases, that will require you to compromise on your overall vision, or to restructure/optimize until performance is good enough to hit the target rate. Although, in most cases, if your vision is that big, I think you would have to make some trade-offs either way, because there are clear limits to how much complexity you can personally handle, as an independent developer.
Can you set bullet’s update time to a changeable variable from within bdx, please (default 60)?
Yes. I already planned to expose the bullet time-step, to enable features like slow motion. However, setting the time-step to anything higher than 1/30 seconds is likely to miss various collision events (especially for faster moving objects), because I don’t use maxSubSteps, or the fixedTimeStep parameter when I call stepSimulation (for those who don’t know what I’m talking about: http://bulletphysics.org/mediawiki-1.5.8/index.php/Stepping_The_World).
Again, I take this approach for the sake of greater system simplicity: If I were to utilize those parameters, I would have to place general logic execution in a callback, which bullet would then call on every substep. In some circumstances, that would work out fine, but in others, it could actually further degrade the frame rate, especially if you’re doing something fairly expensive in your game code.
Yeah wow, I haven’t been here for two years, luckily I suscribe to your youtube. I miss the BGE, there’s something special about being able to work on a game from inside Blender. Exporting assets is easy enough, but I’m excited about BDX being able to package complex scenes, and libGDX as the engine opens up the JVM ecosystem.
I don’t know a lot about GWT but I doubt clojure code could be used. Can you access the libGDX API once it’s compiled to .js? I found it easy to port 2D games between clojure/libgdx and clojurescript/canvas, once I have projects with render loops and draw functions, the rest of the code just works.
Clojure/libgdx builds to android just fine though
If BGX could bring blender scenes to .js/webGL with a javascript API, that would be really exciting.
With libGDX as the engine it’s more a question of what you can do with openGL. It does come with nice high level classes for isometric sprites/models/UI, but at any point in the render loop you can add your own draw call. I don’t know what Goran’s scene rendering pass will look like, but I can assume there will be easy ways to flag blender objects for custom draw passes. You could then designate empties in your scene to be emiters for something like this: http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/particles-instancing/
I also spend a good portion of my time in FP land. I lean more toward strongly typed Haskell derivatives, like Elm, but I know that Clojure is just as powerful, as it builds on the same fundamental principles.
Zoooooom! What was that!?. Oh Nvm this grass is interesting.
The definition of “particle” is not tied to details of implementation. If used as such, a “textured object spawned to face the camera” is indeed a particle, as is anything else that can serve the same role.
I feel strongly that this is not the case. A particle implies a certain number of specialisms/ features which distinguish it from other game objects / entities, otherwise neither the term nor concept would not exist. A particle Is only useful when considered as a member of a system. If this axiom does not hold true then whatever one considers to be a particle is not truly so.
As such, whose a particle in its basic form represents a textured plane (sic) as does Bullet physics represent a physics engine. Except in reality such concretions are merely assumptions / results of the implementation and the necessary feature may be implemented by other means.
Instancing (most games do this – just a mesh with a texture)
Using a VBO that contains all of the particles.
Geometry-based shading.
In terms of how the instances are processed is the key factor to making a good particle system. It is best to reduce the amount of polygons where and when possible, and then make sure that they are all called to the GPU in one batch to reduce CPU usage.
Particles should also use a separate approximated physics engine to improve performance rather than using bullet.
Well, assuming there’s an option to disable the minification process (which HTML5 export seems to automatically apply, even for debug builds), it should be possible to analyze their output, and write the relevant wrappers, but I don’t know how much work that would entail (I doubt that it would be trivial).
I didn’t argue that particles are exactly the same as generic entities. I argued that they could be implemented as entities.
There is no particular “specialism”/feature (common to all particles) that demands a very specific implementation method.
A particle Is only useful when considered as a member of a system.
The usefulness of a particle depends on how well it serves to produce the desired visual output.
If this axiom does not hold true then whatever one considers to be a particle is not truly so.
Is this “axiom” defined somewhere, in relevant programming literature?
I started looking about LibGDX, and notice that it supports Python usage through Jython, and similar functionality for other languages, too (like Scala or Ruby). Would it be possible to use BDX using these “alternate” languages? Have you tried or considered it? It could be a really, really nice feature to support multiple languages out of the box alongside LibGDX’s existing compatibility, especially since the supported languages vary widely and have different pros and cons.
EDIT: Ah, that’s what Clojure is talking about (at least partially). It seems that Jython only works on Desktop platforms (though that might also mean web). Anyway, LibGDX looks pretty good!
There is a JVM implementation of Python called Jython, which would make that possible, but you wouldn’t be able to export to HTML5, because the GWT transpiler can only operate on Java source code, to generate valid JavaScript.
I asked about Python earlier in the thread. Goran replied with the same idea.
No need to guess on something that’s clearly not true.
Just bumping this thread I think it deserves the attention
Thanks, but I think this thread had enough visibility at this point (it feels awkward to hog a spot on the front page, for more than a few days).
Now I actually have to get to work, and deliver.
As MrPutuLips noted, I touched on that previously.
However, taking another glance at the relevant libgdx wiki page, it seems like it’s only supported on desktop, which I find strange; Jython should simply compile to Java bytecode, which should enable it to run wherever Java code can run, including mobile platforms.
HTML5 should be the only exception, because instead of emulating the JVM, GWT actually transpiles Java to JavaScript, so it needs Java source code.
Anyway, LibGDX looks pretty good!
Well, it’s not something that I would want to use directly, even for simple games (the api is not actually that great), but it has some fundamental features that make it a good foundation.
And, of course, the portability has the potential to be extremely valuable.
No, because it’s an axiom of reason. As you say, there is nothing preventing you from implementing particles as entities.
Concerning your design for the engine API, I would be concerned that you are limiting potential future design choices by restricting the access of the developer. In my case, having access to the main loop was quite important. It’s safer to give developers the ability to modify such things, but exposing this as optional behaviour rather than necessary (to avoid unnecessarily verbose APIs for newer developers starting basic projects).
There is nothing in the definition that implies mandatory absence from any written texts.
IE: Mathematical axioms are thoroughly documented in relevant literature, and the same is true for “programming axioms”.
Let’s not confuse “a premise so evident as to be accepted as true without controversy” with an “unwritten rule”.
At this point, I don’t want them know about BDX.
I would like to test both the ideas, and the early engine on a much smaller audience.
So what’s the reason?
Your argument, as it was expressed, essentially reduces down to: “I feel strongly that details of implementation define the general concept of a particle.”.
Feelings alone don’t constitute a valid rationale.
As you say, there is nothing preventing you from implementing particles as entities.
Right, and therefore, the concept of a particle is not defined by implementation details.
I would be concerned that you are limiting potential future design choices by restricting the access of the developer. In my case, having access to the main loop was quite important. It’s safer to give developers the ability to modify such things, but exposing this as optional behaviour rather than necessary (to avoid unnecessarily verbose APIs for newer developers starting basic projects).
Well, I can’t really make specific comments unless I know why “having access to the main loop” was so important (assuming it was even necessary), and if those particular circumstances are sufficiently common to warrant serious consideration.
In any case: I will endeavor to make the best possible decisions in that area, in order to establish a good balance between flexibility and usability.
The definition of a particle, according to most of the written references to their usage, distinguishes between an entity, which may comprise of complex geometry as a mesh, complex physics processing and some form scene operations / data(such as transformations).
A particle, on the other hand, if using geometry at all (for texture purposes) should consist of a single quad (two triangles).
I recognise that you might argue that these are implementation details. But then, so must an entity be. In reality, we don’t concretely identify the details that differentiate “static” objects from animate ones, and we certainly don’t define any object in terms of its system properties.
Though I do not anticipate many other uses would immediately find sufficient need for such control, I do believe that any potential limitation to the API in the early stages may be much less trivial to remove at a later date. (I.E Panda3D hacking builtins, which is now used by many)
I used the additional control provided by a Gameloop class to perform individual system updates (in my particular case, Bullet and the SceneGraph) and to explicitly control the engine without requiring a GameObject to do so, a limitation that I suspect your engine will not suffer from.
By all means, I understand the difficulty that writing a comprehensive API can become, so it does eventually come down to the decision at the moment.
I have yet to read any relevant (not to mention credible) literature that distinguishes particles, as a concept, in terms of their implementation. There are certainly distinctions between common implementation strategies, but that doesn’t support the argument that particles are defined by their implementation.
And as I said:
Although, I can see how that could be confusing, for most people.
A particle, on the other hand, if using geometry at all (for texture purposes) should consist of a single quad (two triangles).
Only if that’s the best implementation strategy for the given case. There are other cases where just one vertex would be enough, or where multiple quads are necessary, to properly express behavior encoded in a vertex shader program.
I recognise that you might argue that these are implementation details. But then, so must an entity be.
And assuming that it is, how would that counter my original argument?
Any game object is just an implementation detail. That’s why they’re specific types, rather than simply being an “Object” which is some loosely defined notion with a component architecture, or other composition based approach. (NB, many would implement a particle system as a component rather than individual particles as entities with a particle component, again, for implementation purposes)
So, in reponse to
I didn’t argue that particles are exactly the same as generic entities. I argued that they could be implemented as entities.
I would argue that yes, there is nothing stopping you, but that does not mean it’s sensible. Otherwise, we wouldn’t bother with the notion of a particle.
I have yet to read any relevant (not to mention credible) literature that distinguishes particles, as a concept, in terms of their implementation. There are certainly distinctions between common implementation strategies, but that doesn’t support the argument that particles are defined by their implementation.
I suspect in part that this derives from the fact that most are more concerned with the implementation and [or] what particles provide rather than the philosophical argument of what they represent.
In the same manner, most game developers would not particularly mind whether an engine uses inheritance or composition for the model of game entities, provided that their game was not hindered by the approach (neglecting personal preference).
I miss the BGE, there’s something special about being able to work on a game from inside Blender. Exporting assets is easy enough, but I’m excited about BDX being able to package complex scenes, and libGDX as the engine opens up the JVM ecosystem.
