Flamadeck
-
Posts
20 -
Joined
-
Last visited
Posts posted by Flamadeck
-
-
2 minutes ago, vladislavbelov said:
It's like:
This format have pluses and minuses, i.e. Blender doesn't support this format. If we should change the format, why we should use the text one? We could use something faster, most binary formats are faster and smaller.
Did you not read the post (considering the fast response that might be true you dirty meme spammer) before writing your reply?
GlTF 2 stands head and shoulders above the other formats in terms of specification, test cases, clearness, speed and features.
There is already a Blender exporter and glTF 2.0 supports specifying an external file for the big data, in binary format.
QuoteSeparate binary blob for arrays
glTF allows specifying an external file for the big data, in binary format. It even supports many common GPU data types, so in practice this file can be moved in chunks directly to the GPU memory. Yes, glTF is the first of these formats that can even be used efficiently as in-engine data.
Even if engines would prefer to import to their own format, like Godot does, glTF is extremely fast to export and import. This makes it ideal for making changes to a complex file in the 3D software and updating them to the 3D engine almost instantly.
-
Recently Godot posted an interesting post detailing the state of standard asset exchange formats for game engines.
Their post goes over previous and even previous version of glTF citing all kinds of problems, from ambiguity defects, crappy libraries to crappy coordinate conventions and even missing functionality for common assets in game engines.
The post conclusion comes with a very unambiguous message:
Why we should all support glTF 2.0 as THE standard asset exchange format for game engines
https://godotengine.org/article/we-should-all-use-gltf-20-export-3d-assets-game-engines
QuoteglTF 2.0: What makes it great?
By just reading the spec, the advantages should become clear. Still, I will detail the key points below:
JSON based
GLTF is a JSON based format. It's very easy to parse and the data already comes typed. This significantly reduces the need to rely on complex third party libraries to read it. Many languages (e.g., Javascript, Python) even support this format natively.
Comparing the size (in lines of code) of both Godot's glTF 2.0 and Collada importers, the result is as follows:
- Collada: ~5000 loc
- glTF 2.0: ~2000 loc
Godot does not even use third party libraries to parse these files. This makes it more evident how simple the format is in comparison.
Theoretically, glTF2 should be less efficient to parse than Collada, as it requires parsing the whole JSON into memory. Collada can be streamed in by using a SAX XML parser but, in practice, glTF beats Collada hands down. This is because (besides many Collada exporters not obeying the specification, so they can't be parsed as SAX anyway) glTF has yet another killer feature:
Separate binary blob for arrays
glTF allows specifying an external file for the big data, in binary format. It even supports many common GPU data types, so in practice this file can be moved in chunks directly to the GPU memory. Yes, glTF is the first of these formats that can even be used efficiently as in-engine data.
Even if engines would prefer to import to their own format, like Godot does, glTF is extremely fast to export and import. This makes it ideal for making changes to a complex file in the 3D software and updating them to the 3D engine almost instantly.
No ambiguity
glTF's file structure is crystal clear. No extra or redundant data exists. There is only one way the scene definition can be understood, which gives no room for exporters to take shortcuts. It also makes life for importers simpler, warranting that all existing scenes will work on the first implementation attempt.
Collections of objects of the same type are stored in JSON arrays and referenced by indices. No more confusing IDs.
There is also no support for different coordinate systems or units, and this is great. Quoting one of the first paragraphs of the specification:
- glTF uses a right-handed coordinate system, that is, the cross product of X and Y yields Z. glTF defines the y axis as up.
- The units for all linear distances are meters.
- All angles are in radians.
- Positive rotation is counterclockwise.
Just one simple use case to care about. No extra conversions. All work is left to the exporter. As there are usually way more importers than exporters, this is an excellent design decision.
Modern features
glTF 2.0 fully supports skeletons and morph targets, which can be parsed easily and unambiguously.
It also supports PBR based materials using the Disney/Unreal format, which is what most engines and 3D modelling applications use nowadays, with albedo, metallic, roughness, normal, emission and ambient occlusion. It also handles two-sidedness and transparent materials, including alpha to coverage.
Extensions for handling shader material graphs are in the work.
Great animation support
Animation support is also well done. glTF 2.0 supports multiple animations per file, which is ideal for exporting character actions (though be careful with some official examples, they are old and incomplete). It also supports many key interpolation types, such as Catmull Rom and Cubic Spline.
Animations are also stored in the binary file, so they can be loaded quickly.
Clean documentation
The specification is very complete, I personally found it well worded and not lacking in any area. There are many sample files to test all functions.
Flexible extension support
glTF uses the same extension system as other Khronos specifications, which is proven to be centralized and well organized.
Strong backing
glTF is developed by individuals from many companies, such as Microsoft, Unity, Google, Adobe, NVidia, Oculus, etc. in collaboration with Khronos.
Best of all, it's completely open and everyone can contribute!
glTF is an open standard and the development process is also transparent.
Support glTF!
For glTF to succeed, it needs strong developer adoption. Ask your favorite 3D modelling software or engine developer to support it!
Currently, the Blender exporter is in the works and not complete, and there is no support at all for Autodesk products (export plug-ins need to be written).
This is the best chance we'll ever have in a long time for a proper, open standard. Let's work together to make it happen!
Would the glTF 2.0 format be interesting for the 0 A.D. developers to implement?
A standard asset exchange format for game engines with
a rich feature set and good documentation, tests, implementation and software ecosystem support would
be great for asset developers and modders.
What does everyone think about glTF 2.0?
Is it an interesting format to support or not? Reply and discuss in this thread.
Links:
https://en.wikipedia.org/wiki/GlTF
https://github.com/KhronosGroup/glTF
https://github.com/KhronosGroup/glTF/blob/master/README.md
https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md
https://github.com/KhronosGroup/glTF-Sample-Models
https://github.com/KhronosGroup/glTF-Blender-Exporter
-
SDL 2.0 has been officially released.
The game 0ad can now be adapted for it because the api is stable enough.
Offers many new features a few important ones are support for OpenGL 3.0 and higher, support for OpenGL ES, better keyboard support(scancodes vs keycodes, etc), Proper unicode inputand Lots of old annoyances from 1.2 are gone.
Announcement on forums.libsdl.org
http://forums.libsdl...opic.php?t=9375
Adopting the new release can improve 0ad, make it more maintainable, etc.
-
For your arrows, I've never programmed on the GPU. So that's nothing for me (yet).
And about the buildings. It's not possible to only make half of a building visible. This is because the inside of a building is not textured (it's completely transparant in fact). So it would give strange problems with being able to look through the walls. Currently, the building is made visible when the tile in the middle of the building is visible.
I meant things like walls that consist of multiple sections, by uncovering a piece of the wall you don't want that the whole wall suddenly becomes visible, especially if it's a very long wall.
Drawing the range overlays, with modern OpenGL features can actually be done mostly, completely on the GPU.
Also calculating the arrow paths can also done this way using OpenCL on the GPU.
(OpenCL works on CPU and GPU)
Modern GPU's have massive parallelism that you can exploit not only for graphics but for physics and other things too.
The calculation of the arrows path and physical stuff is a good example of a parallelizable workload that you can run very well on the GPU.
-
@sanderd17
Thanks! Didn't know the tools where this developped already (since 0 A.D. is still in alpha).
Don't mind that the models are not very detailed and the animations not realistic enough.
Don't really care about graphics. Use to play games with much less detailed graphics than this.
-
2
-
-
@FeXoR
Please read my post a bit better than this.
By aiming for better GPU's we can push more calculations on the GPU, this allows for doing more non-graphical interesting things with our computational budget on the CPU (and GPU too, see instancing).
When I said computational-intense features I meant all kinds of things, including AI and physics.
The whole idea on setting minimum here is to be able to do more with the GPU, not necessarily fancy graphics.
Mostly to make sure we don't have to use the CPU for all kinds of things, which would make 0 A.D. unplayable.
Where you say it's okay to drop support, you say other resources. What kind would that be? We're talking about a computer game here where calculation power and memory are almost the only resources that matter.
You make the assumption that a weak graphics card can produce nice graphics but the cutoff point would be where there is unnecessary fancy features. This is not true! A weak graphics card or cpu or too little ram means you won't be able to run 0 A.D. on low detail anyway.
-
1
-
-
In Rise and Fall: Civilizations at War there is a First Person Hero mode.
The computergame Savage had another concept with combining RTS and FPS/RPG.
Is it possible to implement a mod that gives this?
Minimum is:
- Camera perspective: being able to have a first person/third person perspective similar to FPS games
- Being able to walk, move using usual buttons similar to FPS games.
- Being able to do attacks on enemies using weapons similar to FPS games.
Is the game engine capable of supporting this kind of mod?
Would supporting it be requiring no, a little, or complete redevelopment of the game engine?
Camera perspective looks like a sufficient general way would be convenient for scripted scenario's in campaing stories.
Being able to easily record scripted scenario's for campaign stories would benefit from walking instructions.
The third, don't know right now, maybe record scripted scenario's for campaign stories?
Graphics don't really matter. Mostly being able to do the game mechanics the way just explained.
-
What if you would go a different way.
Go the other way. Make buildings visible dependent on what tiles are visible! With of course making only the building, or part of the building visible depending on the tiles visible. Should solve most issues to to tackle the problem this way.
-
The ballistic trajectories added are done via the numerical method to solve a root for a bi-quadratic function. I could have done it by hand, but to calculate the real trajectories, you get complicated functions, with lots of operations. So probably not doable in the game for every arrow. Using the numeric methods in the draft does mean that, if the unit is almost out of range, it won't find a trajectory. And there are also some sign problems (S can only shoot upwards and forwards, not downwards), so sometimes you have to imagine the mirrored trajectory.
You would need this to calculate obstructions though (I heard people want walls and buildings to obstruct arrows), so I'm not throwing it away for now. But the complicatedness of the real traject shows in some way how really simple a basic range check is.
Since the calculation of one arrow does not really depend upon another you could parallelize it.
Let it run on the GPU using OpenCL.
Alternatively you could also implement the equation as an animation, have archers two poses 1 for max length and one for higher, and do other things to limit the number of operations.
-
Short: The old fixed-function pipeline should have been removed already!
The oldest graphic card I use is an ATI radeon X1600 supporting OpenGL 2.1.
(Which will be replaced this year with a computer that has an ATI radeon HD7770 supporting OpenGL 4.3)
Very old hardware in this case is more like approaching 15 years.
The percentage of people not being able to play is very small.
It will help create a good game and weed out very old graphic cards, setups that would hold relative computational-intense features back.
The old fixed-function pipeline is deprecated already. Using it is technically a bad idea in all situations with new development, end of story!
You need to make something that is great when released.
It's important that 0 A.D. runs great on most hardware.
Not all setups out there whatsoever, which is not gonna happen anyway.
Features in newer OpenGL versions like instancing can be really helpful with improving performance
SDL 2 is already in release candidate status.
Hope that 0 A.D. will have an OpenGL ES 3 renderer in the future.
(Fun OpenGL ES3 fact, you can have the OpenGL ES3 context in systems with full OpenGL 4.3 or later.)
-
Here is some very interesting approach to improving performance:
http://www.reddit.co...uce_nearnative/
Achieving near native performance with Javascript.
-
RaFs hero mode is the most fun thing I have seen in the last 15 years in computer games.
A more worked out game would really show how fun the hero mode could be, sadly the studio didn't got the necessary resources to fully develop the game and hastly finished it.
Another game that did a similar thing was Savage: http://en.wikipedia.org/wiki/Savage:_The_Battle_for_Newerth
So sad nobody seems to be able to develop this kind of thing fully.
-
A hero mode where you only have hero units with gametypes originally from shooters:
- death match,
- team deathmatch,
- capture the flag,
- team capture the flag
- last man standing,
- team last man standing
- and other things.
Because the heroes have lots of hitpoints, this could be very interesting.
Have artifacts spread over the map to have healing and other things.
- death match,
-
It's more a suggestion for the game engine. Since it suppose to be able to be used for other games as well.
In many situations, maybe in 0 A.D. also, it would be handy to have teleportation ports/portals.
Mods may want to add fantasy stuff.
Or another game might want to do something that needs them.
-
well i think even in theory it's obvious that it's more important to select all units of a type rather than all units of the same rank... in the heat of the battle you have to use different unit types to counter your enemy's units. even if the rank system will be beefed up considerably, ranks don't really matter: they improve units, but they do not change their roles. by the playtesting i did i can confirm it's unhandy.
so i think you should definitely change it but i agree insofar as that the other issues i mentioned are more urgent. you should have somebody look into them, also into this one. with these issues solved you'd definitely have AAA land combat already. best
The ai should intelligently position my units.
Seriously, please don't accidently add a layer of micro management with this.
I want my units to optimize as much as they can on themselves.
-
It would be neat to be able to edit a map while simultaneously letting it be playtested.
I remember there was a game a few years ago that had modifiable terrains.
Means it can be done.
-
Hmm, the hidden terrain thing sounds a bit annoying. Maybe it'd be fine just to have the line follow the terrain even in SoD? The terrain height in SoD is already not well hidden from players (they can e.g. use the camera zoom to detect hills and valleys, or click in SoD and look at the little animated movement-order confirmation symbol that we haven't added yet, or just modify the shaders if they want to cheat trivially), so exposing the same information through rally point marker lines (which is a pretty slow and unreliable method) wouldn't hurt much more. If it turns out to be a problem in practice and players exploit it, we can fix it then - it doesn't seem certain to me that it will be, so it's probably best to avoid the effort and complexity now and do the simpler terrain-height-exposing thing.
(I think it's more important to hide the existence of enemy buildings (especially walls) than the terrain, so it's probably still worthwhile having it stop using the full pathfinder data and doing the straight-line thing once it reaches SoD, even if it's still going to expose terrain data.)
Assuming the rally point paths get recalculated whenever the player selects a building in order to see its rally point path, I think it's fine to never update it automatically - players aren't going to look at it for more than a few seconds so it won't get very out of date, and if it does then they can just reselect the building manually.
(There isn't any way of detecting when a path becomes invalid (other than recalculating from scratch and seeing if it's the same) - it wouldn't be sufficient to check for buildings that are on the path, since destroying a building that's not on the path might open up a new shorter route and change the path.)
Then when someting changes how paths can be calculated, you could let that trigger the pathfinder and recalculate rally points?
-
Still working on this, just really swamped with work right now. I've been editing the shaders to allow the rally point lines to be rendered inside the SoD and I've also added some generic code to create dashed lines.
A few issues remain which I'd like to discuss:
1) In the SoD, the idea was to render a dashed straight line from the edge of the SoD to the rally point itself so that the user doesn't get any information about the terrain or enemy buildings from the path. A problem however is that in the SoD, everything is still rendered, only entirely in black. That means the dashed rally point line can still be obstructed visually by black terrain and buildings at some camera angles. Without entirely rewriting the way the SoD is rendered (which I would not recommend), I suppose the best way would be to add a rendering pass that goes after everything else and which doesn't care about depth testing and whatnot so that it would just get drawn through any terrain inside the SoD or something.
2) Right now the long-range pathfinder is used to build an initial path which is then further post-processed. What should happen if a building gets placed smack in the middle of the rally point line? Do we ignore it or recalculate? I'd also be interested to know how to detect this in code, as I'm not yet very familiar with the internals of the pathfinder.
The second one is easy.
Because there is a building, the units cannot go there.
Use the same thing you use when the waypoint is placed in an inaccessible area.
Just use two waypoint markers. One that tells the user where he places it and when that isn't reachable make it look different and add a second to where the units will be.
-
So far I really like the graphical style.
It has enough detail to see what there is and the system requirements seem reasonable.
For later stages, please make everything very stable so it doesn't crash or anything.
When the game is finished I would like to be able to save games and load them.
Also when doing multi-player games. The names (and maybe other identifiers) of the players could be stored also to set them back on the right place.
Once had a game that didn't do that, we could load that saved game but ended up in the wrong place.
A random map generator would come in very handy, especially for mod makers, with the ability to save the generated map.
Also, and I know this isn't going to be soon, would like to have a hero mode such in RaF:CaW.
It was kick-@#$% fantastic but many features that where promised, that would have made it even more fun, weren't implemented.
If people don't like it, maker it configurable so it can be enabled or disabled by the person who sets it up.
glTF2, 0 A.D. and Godot
in Game Development & Technical Discussion
Posted · Edited by Flamadeck
Fixed capitalization
I know. Have you seen how other formats are structuring their data? It's much worse. Some things so much worse.
Also the Godot open source game engine supports glTF2 natively.
Do not fear Blender add-ons dude! Blender add-ons are necessary to go from noob to pro!
Many pros use them to enhance, accelerate and improve their workflow and artistic output.