September 18, 2014 at 15:22 #326
Huh? Just pack all textures into one and set the UV coordinates properly. No blending involved.September 18, 2014 at 16:17 #328
You can bake the textures and then overlay them in gimp, just like in Blend-A-Race game usng a single texture with all the baked stuff. But this is loosing its functionality, for example see this: http://www.cgmasters.net/free-tutorials/fps-mouselook-script-plus-real-text/
And you could also download the blend file.September 18, 2014 at 18:39 #329
I don’t quite know if we talk about the same topic. I meant that you don’t need to do any baking, blending or something else to use an atlas texture. It has nothing to do with pre-baked lights or AO at all.September 18, 2014 at 20:59 #330
You are right, my mistake. I was thinking about baking and lightmaps 🙂
Can you add a visual representation for the point light “Radius”, like circles, to make the radius more clear?September 20, 2014 at 08:45 #331
Visualizing point lights sounds useful. I will do that as soon as I have time for it 🙂September 20, 2014 at 22:13 #332
Nice and thx.September 26, 2014 at 01:54 #362brycehenleyParticipant
One of my game project teammates, after switching from Maratis, pointed out the missing animation settings. So I decided to make a feature request for in editor animation tools and or a controlled animation playback options. These are not incredibly important because most of the animation data is handled in lua script, but it would make a nice addition to the in editor features.September 26, 2014 at 09:06 #363
Ok. I added all those features to the road-map on GitHub.
They are all staged for 1.0 the latest but I think most of these smaller features will arrive in 0.5.
Those are the most difficult things I have to fix for 0.4 to arrive.
Here are all planned features for 1.0: https://github.com/Sponk/NeoEditor/issues?q=is%3Aopen+is%3Aissue
Please tell me which ones to introduce in 0.5 🙂September 26, 2014 at 17:26 #367September 29, 2014 at 17:47 #399
You could do that with a custom shader. The default shader should be clean and simple since you won’t use such advanced features on most surfaces.
What actually would be very nice is a tutorial on how to write custom GLSL code for use with Neo and maybe some sort catalogue to share user made materials.September 30, 2014 at 17:54 #402
I agree!October 2, 2014 at 17:12 #406
While i was looking at OpenGl books and stuff (that can be found around the net) i found, that what i was looking for can be done in GLSL without the need to touch the engine c++ code, but of course Gl_Decal could be added and multiple to the blending and stuff with just a simple line of code, but anyway. So yeah, a tut about how to use the glsl with NeoEditor would be nice to have for in the future!
How about: Deferred shading
Deferred shading wiki
That would make the engine have a next-gen lightening.October 2, 2014 at 18:29 #407
Deferred rendering is possible but not feasible. We would need to to maintain multiple rendering pipelines for mobile/web/pc and would still need a forward renderer for transparencies. You would also loose the possibility to use custom GLSL shaders for surfaces.
The (in my opinion) better solution is to iterate further on the current renderer and create something new and unique. You can see what AMD did for example: https://diglib.eg.org/EG/DL/conf/EG2012/short/005-008.pdf.abstract.pdf
We need to innovate. Simply doing the same as everyone else is not feasible since we don’t have the resources to compete with them in their own game.
Btw: “Next-Gen” is purely marketing. You can sell everything as “Next-Gen” with enough advertisement. The same goes for “Triple A”.October 3, 2014 at 21:10 #413
I like that “Forward+” render. Yeah, the game studious have a plenty of people to make photo-real games and call them “AAA games”.
How about OpenGL extension “ARB_draw_instanced” ARB_draw_instanced for hardware instancing, what do you think?October 3, 2014 at 23:15 #414
That extension is OpenGL 2.1 so I think it should in principal be safe to use.
The biggest challenge in implementing hardware instancing is batching equal geometry together. I think that should be done whenever a new static mesh is added to the scene. That could bring more performance.
You would also load the material one time only for those batched objects so even more savings there.
Let’s see if we can put that in 0.5 😀
- You must be logged in to reply to this topic.