- This topic has 156 replies, 6 voices, and was last updated 9 years, 4 months ago by
.
-
Posts
-
I just remembered a nice audio lib that maybe should be used instead of OpenAL as that is dead and has a shit API: http://sol.gfxile.net/soloud/
Zlib licensed like the engine.
Maybe something to consider, just posted here before I forget because you weren’t in irc atm 🙂
Thank you for pointing me to this project. I think we’ll keep using OpenAL-Soft for now though since we already have working code using it.
Now to something completely different: There are many huge changes since the last Neo release 0.4 but we are not ready to ship 0.5 yet. Should there be more frequent point releases to deliver a semi-stable experience between releases?
I think, having a material editor, is really what Neo needs. Instead of exporting from the blender the user should build the material and add the textures in the editor.
Exporting from Blender using the old plugin is outdated by now. You should export to DAE or something and use that directly. Animations need some testing though.
The material editor is non-functional for now because of that fact. If I have time I will create a new file format for saving material data for every object in the scene so every object can have unique textures defined in the Neo Editor.
The Godot engine dev have made a script Better Collada Exporter for Blender
You could get ideas from blender for the material editor.I think materials should be handled similar to the Torque3D Game Engine. They put all information about the material in a script and simply execute that script to set up all textures and shaders.
We could achieve that by using Lua scripts and the new Lua API that gives you full control over the material. The material editor should be implemented as an external tool that is launched whenever the user wants to edit the material of an object, this way we can keep the editor small and fast.
The plan is not to re-create what Blender does but to merely give the opportunity to customize every object independently without switching to Blender. All UV maps need to be created in Blender and it will remain this way.
Btw: Thanks for the link. I had no problems with the default exporter yet, but I will try this script.
I like the idea. This script is it gonna be auto generated in the material editor or you write it?
“”All UV maps need to be created in Blender and it will remain this way.””
Just like with other game engine, thats natural.I forgot to say, about the script, that it can export more than the maratis, but have not tested it.
I was thinking why not use some render library like bgfx bgfx – Cross-platform rendering library
Diverting some maintenance of the render could save you work and you could focus on different tasks.
Here some quotes from author:“bgfx is made to be portable without sacrificing performance. For example, if you made game with bgfx for mobile (using GLES2 backend) and used ETC2 textures for you content, and you want to port your game to desktop and use DX11, you don’t need to change anything about those textures, because bgfx internally handles them properly. So even DX11 doesn’t support ETC2 textures, it will display them correctly. That allows you to do port as quickly as possible, and then deal with content if that’s necessary. It works the same in other direction too. For example you compress something with DXT5 and mobile GPU doesn’t support it, texture will be uncompressed and used that way.
bgfx uses single shader source which is written in GLSL style syntax, and then it gets translated to ESSL, HLSL, GLSL, etc.”“Major differences between other rendering engines is that bgfx is not trying to be engine, but rather just rendering library (bring your own engine). It doesn’t do lighting, it doesn’t do shadows, object culling, loading assets, or any of higher level concepts.”
“It’s on higher level than GLES, GL, DX, but on lower level than Ogre.”
“-Rendering can be run in a thread, all of it:
Yup, that’s exactly how bgfx works, it has API thread, and rendering thread, or all can be single-threaded on platforms that don’t support it. And it’s all implemented inside library so running multi-threaded or single-threaded is completely invisible to user of library.”“bgfx philosophy is to be graphics API agnostic. So if someone wants DX9 for any reason, like shipping games on XP in 2015, they can do that.”
“But other than that, if it lacks any extension you’re using in GLES2, or you need some feature to support your feature set, just let me know and I’ll add support for it.”
“Another feature of bgfx is that it’s not just sending things in order you submit, but rather it sorts primitives before rendering. This allows engine to go thru scene only once and submit rendering for all passes at once (f.e. no separate shadow, and rendering pass, just submit both passes at the same place). There is no need to go thru scene multiple times for multiple passes, which lowers amount of data that needs to be loaded from RAM to cache when processing scene, and in most of cases also makes scene code simpler.”
“bgfx shader language is closest to GLSL, and it uses subset compatible with HLSL. If you seen SteamDevDays talk from Valve about their cross platform shader solution, bgfx’s shader language is very similar, they just use ANTLR parser to enforce correctness, bgfx uses some preprocessor magic stuff. Which is not as robust as Valve’s solution, but bgfx supports lower end shaders than Valve, and making shader language more robust in bgfx is ongoing effort.”
That library looks really nice!
This might just bring the new graphics I am trying to achieve.I will look into it any maybe create a small demo. First I need to do more API work though,
the C++ API needs work.Thank you for that link 🙂
In the long run, yes. But for the short term we are better off with the current version since I have not much time to work on stuff right now.
By the way: You might want to test the new version a little. I will release a complete tutorial for using Neo soon since the way you use it changed completely.
One more thing:
Release 0.5 is near!Just a little more testing and fine-tuning left!
I spent the last weekend porting the engine to Windows again because of some regressions due to huge restructuring. It works now on MinGW32-w64 and VS2013 while the Clang support on Windows is still bad.
There are still some issues on Windows that need to be fixed (NeoGui does not work somehow)
Another problem are translations. The current ones are still ok but nowhere near complete. It’s no blocker for 0.5 but important for the 1.0 release.
Akira_San: You mentioned that you want to work on the Bulgarian translation on GitHub. Just open the “bulgarian.csv” file with LibreOffice Calc or Excel and insert all new strings. The list is in the file “translations.txt” in the “Neo/NeoEditor” directory. Be sure to save as UTF8 with comma as the delimiter.
Have a nice day!
- You must be logged in to reply to this topic.