Update to support OGRE 1.10 & Bullet 2.86

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 07 Jul 2017, 07:04

NaN {l Wrote}:Looking at the code, you should be able to enable physics debug drawing by pressing 'L' key. It will draw collision shape wireframes and contact points.

Thank you for that. I have looked at the collision meshes in-game. They aren't complex; ridiculously simple for characters actually. They're often just some simple 'hedron surrounding the character. However, some enemies such as Biting Bark and Stone Imp have multiple overlapping collision bodies. I would imagine this would cause problems; wouldn't it?

GunChleoc {l Wrote}:[Slow performance when running under Valgrind] is normal, because Valgrind itself uses up a lot of performance, slowing down your machine.

Is the overhead from Valgrind proportional to the program that I'm running under it?

charlie {l Wrote}:Liam32: I would post in the Showcase & Collaboration. Post a thread asking for programmers and artists, give some background and some information on your own goals with the project. Call it "Lips of Suna Revival" or something to that effect.

I already posted this in that forum, but no replies. However, I didn't really share my vision of the project's future, said nothing but what I want done in the short term. I guess I didn't make it too exciting.
My mind is full of ideas of what Lips of Suna should become, but I need more help than I'm getting to achieve that.

I would kill for another active contributor to work with that was more skilled at programming than me. (Don't take that one literally).

There are some simpler, short-term goals that I've already talked about that involve little changes to the existing codebase.
But if I had people working with me, I would rather do a big overhaul of the codebase. I would switch to a different engine, and have the lua codebase rewritten in a different language and a cleaner coding style. This would make contributions easier once done, but I would need far more help than I'm getting to get there.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby xenodora » 07 Jul 2017, 16:30

LiamM32 {l Wrote}:
farrer {l Wrote}:I would recommend checking which are LoS bottlenecks: CPU or GPU? LoS', Ogre's or Bullet's code? The approach to optimize the performance depends a lot on what is causing the performance lost, and anyone who'll check this must before check what is causing that. Otherwise, you could be trying to optimize something that isn't the current LoS' bigger bottleneck actually.

I think it's very likely CPU-bound, as the FPS counter often reports over 120 but there's an occasional very long frame. How do I actually measure where the bottlenecks lie?

There is a basic high level profiling tool already in the game. This just gives you how many milliseconds in spends in each section of the main loop, and some other sections. To use this press "T" to bring up the chat input window, and then type "/prof" to bring up a text widget thing which shows the table of stats. You can reset the gathered stats by using the command "/prof_reset".

You'll probably need to use "/prof_reset" after things have finished loading, as loading will likely skew many stats.

The table brought "/prof" is likely to be badly formatted due to line wrapping, and need bumping against the top and bottom edges of the screen to scroll, but it should be legible enough. Changing the UI size in the options menu might help.

From my experience so far, the lions share is in the "parallel" section (rendering and physics simulation), but "garbage" (Lua garbage collector) frequently has a worst case of about 30ms for me. From what I can tell, this is brought upon by the garbage collector doing a full collection every 5 seconds, and I suspect the main source of hiccups in the frame rate.

The main loop and profiling is mostly in "data/lipsofsuna/main/main.lua" but other bits can be found by searching for "timing:start_action" in "data/lipsofsuna".
LiamM32 {l Wrote}:
farrer {l Wrote}:But, unfortunately, as LoS seems to use a lot of very particular shaders, it'll probably be a HUGE task to port the code to Ogre's 2.1 branch.

I would rather learn GLSL and write better shaders before porting to OGRE 2.1.

If you're looking to mess around with GLSL shaders and stuff, I suggest looking for .frag, .vert, .material and .program files in "data/lipsofsuna".
User avatar
xenodora
 
Posts: 27
Joined: 05 Jun 2016, 15:11

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 11 Jul 2017, 00:47

Here my table from the built-in profiler in-game:
lipsofsuna-profiler.jpg


This is on my desktop with Intel Core i5 4570 3.2GHz quad-core.

xenodora {l Wrote}:If you're looking to mess around with GLSL shaders and stuff, I suggest looking for .frag, .vert, .material and .program files in "data/lipsofsuna".

Thank you. But how do I set an object to use the right shader?
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 11 Jul 2017, 10:02

I have started my attempt at changing the shaders in Lips of Suna. I hope that this isn't an issue for anyone, but I'm not going for pure cel-shading, but approaching cel-shaded. The reason for this is that pure cel-shading is hard to get right, and makes depth-perception harder. I suspect that "approaching cel-shaded" will be much easier to get right. Team Fortress 2 is an existing game which is approaching cel-shaded, but still farther from cel-shaded than what I'm aiming for.

To start, I took this GLSL tutorial. It only teaches the 2d stuff, but I figured out how to generate this image in Shadertoy:
celramp1.jpg
My shader ramp, generated with GLSL
celramp1.jpg (1.22 KiB) Viewed 461 times

Without changing any of Lips of Suna's GLSL code, I use this image as a shader ramp to replace "data/lipsofsuna/character/celshading/celramp1.png", which previously looked like this:
celramp1~.jpg
Old shader ramp
celramp1~.jpg (1004 Bytes) Viewed 461 times

The horizontal component is for diffuse, while the vertical is for specular. Ignoring specular for a moment, here is what the game looks like with this new shader ramp.
lips-of-suna_new-shading.jpg
Screenshot of game with new shader ramp

I'll have to mix my ramp image with grey, as the contrast between shadows and highlights is way too strong. Another idea I was thinking to stop it from looking too bright at certain angles is to have a ramp that varies based on viewing angle. At grazing angles, the "lit" part of the ramp would be smaller.

Another observation I have noticed is that some objects don't have any ambient light. The hair is totally black on the unlit side; a stark contrast from the skin and everything else.
Last edited by LiamM32 on 11 Jul 2017, 18:34, edited 1 time in total.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby GunChleoc » 11 Jul 2017, 13:19

LiamM32 {l Wrote}:
GunChleoc {l Wrote}:[Slow performance when running under Valgrind] is normal, because Valgrind itself uses up a lot of performance, slowing down your machine.

Is the overhead from Valgrind proportional to the program that I'm running under it?

I don't know.
User avatar
GunChleoc
 
Posts: 261
Joined: 20 Sep 2012, 22:45

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 12 Jul 2017, 02:17

I know that Ogre 1.10 supports OpenGL 3.0+. They say that it's the "default", but how do I know if Lips of Suna is using it.

I notice that the glsl shader files start with "#version 120". Does this mean it's using older OpenGL? I've been trying to convert them to 1.50 or 3.30, but Lips of Suna then crashes on start-up.

EDIT: I am trying to edit data/lipsofsuna/character/celshading/diffskin1.frag, and then I'll apply my changes to other similar files. I have discovered that strangely, having the diffuse rgb values to significantly less than 0.5 will make the characters completely black. Setting it to 0.5 gives them some very faint light. Why would this be?
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby farrer » 12 Jul 2017, 13:32

LiamM32 {l Wrote}:I know that Ogre 1.10 supports OpenGL 3.0+. They say that it's the "default", but how do I know if Lips of Suna is using it.


You should look at where in the code the RenderSystem is created. On a quick search, at render.cpp:
{l Code}: {l Select All Code}
bool LIRenRender::init_window (
   LIRenVideomode*                  mode,
   Ogre::RenderSystemCapabilities*& retry)
{
   /* Initialize the Ogre root. */
   root = new Ogre::Root("", "", "");

   /* Load plugins. */
   load_plugin ("RenderSystem_GL");
   load_plugin ("Plugin_OctreeSceneManager");
   load_plugin ("Plugin_ParticleFX");

   /* Make sure that the required plugins were loaded. */
   if (!check_plugin ("GL RenderSystem"))
   {
      retry = NULL;
      return 0;
   }

   /* Initialize the render system. */
   render_system = root->getRenderSystemByName ("OpenGL Rendering Subsystem");
   if (!(render_system->getName () == "OpenGL Rendering Subsystem"))
   {
      retry = NULL;
      return 0;
   }
(...)


It's using the default OpenGL, which isn't GL3+. You should change that accordingly, if I do remember it on Ogre 1.10:

{l Code}: {l Select All Code}
load_plugin ("RenderSystem_GL3Plus");
(...)
root->getRenderSystemByName("GL 3+ RenderSystem")
if (!(render_system->getName () == "GL 3+ RenderSystem"))
(...)


LiamM32 {l Wrote}:I notice that the glsl shader files start with "#version 120". Does this mean it's using older OpenGL? I've been trying to convert them to 1.50 or 3.30, but Lips of Suna then crashes on start-up.


It does mean that 1.2 version is the minimum GLSL version required to run the shader (and that the shader code will follow the syntax and rules of GLSL 1.2). Note that the GLSL version and OpenGL version aren't the same thing.
User avatar
farrer
 
Posts: 67
Joined: 24 Feb 2014, 21:00

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby xenodora » 14 Jul 2017, 16:48

LiamM32 {l Wrote}:
NaN {l Wrote}:Looking at the code, you should be able to enable physics debug drawing by pressing 'L' key. It will draw collision shape wireframes and contact points.

Thank you for that. I have looked at the collision meshes in-game. They aren't complex; ridiculously simple for characters actually. They're often just some simple 'hedron surrounding the character. However, some enemies such as Biting Bark and Stone Imp have multiple overlapping collision bodies. I would imagine this would cause problems; wouldn't it?

The Blender files can have a separate layer for defining the physics shape of an object. If this is absent from the .blend or the exported .lmdl file, Lips of Suna will default to convex hull built from all the vertices in the model's mesh in its rest pose. From what I've seen of Bullet's rendering of convex hulls is that it renders a polyline visiting each of the vertexes in the hull, and not a mesh of all the surface polygons; so this results in a confusing cloud of lines rather than a clear shape. Although converting a render mesh into a convex hull works as a quick and dirty solution, it can easily result in physics shapes with way too much detail, and not line up well with the actual shape.
LiamM32 {l Wrote}:
GunChleoc {l Wrote}:[Slow performance when running under Valgrind] is normal, because Valgrind itself uses up a lot of performance, slowing down your machine.

Is the overhead from Valgrind proportional to the program that I'm running under it?

In my experience with using Valgrind in memcheck mode is that programs run at 1/10th of the speed or worse when compared to normal.


LiamM32 {l Wrote}:Here my table from the built-in profiler in-game:
lipsofsuna-profiler.jpg


This is on my desktop with Intel Core i5 4570 3.2GHz quad-core.


From looking at that table, aside from the expect garbage collector, it appears to be spending occasional blocks of time in the terrain loader ("terrainL"), the terrain chunk manager ("terrainC"), object chunk manager ("objects"), object server ("objectS"), and object client ("objectC"). From a guess, the delays are caused by it spending its time loading chunks of terrain, the objects on them, and building the graphics for them.

LiamM32 {l Wrote}:
xenodora {l Wrote}:If you're looking to mess around with GLSL shaders and stuff, I suggest looking for .frag, .vert, .material and .program files in "data/lipsofsuna".

Thank you. But how do I set an object to use the right shader?

I don't have a definite answer for you at the moment. From a quick look it appears that materials are set by default in the Lua code. Although there appears to be some facilities in the code for setting the material of actors, it doesn't appear to be utilised in the .json spec files. Supposedly setting "material" field in a "ActorSkinSpec" type should work. However, the only instance of "ActorSkinSpec" I've found is in the Aer's spec file "data/lipsofsuna/actors/aer/specs.json" (Aer is the human race). I imagine adding a "material" field to this and copying it over to the spec files of other critters would work, but I haven't tried this.

I haven't had time to look around at general objects and terrain yet.
User avatar
xenodora
 
Posts: 27
Joined: 05 Jun 2016, 15:11

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby xenodora » 14 Jul 2017, 18:14

LiamM32 {l Wrote}:I have started my attempt at changing the shaders in Lips of Suna. I hope that this isn't an issue for anyone, but I'm not going for pure cel-shading, but approaching cel-shaded. The reason for this is that pure cel-shading is hard to get right, and makes depth-perception harder. I suspect that "approaching cel-shaded" will be much easier to get right. Team Fortress 2 is an existing game which is approaching cel-shaded, but still farther from cel-shaded than what I'm aiming for.

To start, I took this GLSL tutorial. It only teaches the 2d stuff, but I figured out how to generate this image in Shadertoy:
celramp1.jpg

Without changing any of Lips of Suna's GLSL code, I use this image as a shader ramp to replace "data/lipsofsuna/character/celshading/celramp1.png", which previously looked like this:
celramp1~.jpg

The horizontal component is for diffuse, while the vertical is for specular. Ignoring specular for a moment, here is what the game looks like with this new shader ramp.
lips-of-suna_new-shading.jpg

I'll have to mix my ramp image with grey, as the contrast between shadows and highlights is way too strong. Another idea I was thinking to stop it from looking too bright at certain angles is to have a ramp that varies based on viewing angle. At grazing angles, the "lit" part of the ramp would be smaller.


To get rid of the white out, you'll need to either darken the maximum values in your table, or make the ramp up to white less sharp.

To really improve the cel shading effect, I think you will have to look into modifying the GLSL fragment shaders.

There are two main functions of interest in the cel-shading technique used in LoS. The first is los_blinn_phong() in "data/lipsofsuna/character/celshading/templates/celshading.template", this computes diffuse light and specular light intensities from a light source, along with the attenuation. The second is los_cel_shading_skin() in "data/lipsofsuna/character/celshading/templates/los_cel_shading_skin.frag", which computes a cel shaded values for characters. There is also a third function los_cel_shading() in "data/lipsofsuna/character/celshading/templates/los_cel_shading.frag", but this is largely identical to los_cel_shading_skin() and skipped for this discussion.

Below is the commented code for these two functions.
{l Code}: {l Select All Code}
/**
This computes the brightness of the diffuse and specular components of a light source, and also the attenuation.
@param lv Light Vector, the position relative to the fragment of the light source.
@param ev Eye Vector, the position of the eye relative to the fragment
@param ld Light Direction, ??? unused.
@param eq Light attenuation equation constants: attentuation = 1 / (l.y + l.z * dist + l.w * dist * dist) note: l.x is not used
@param normal The normal unit vector of the fragment.
@param shininess Shininess, an exponent applied to how closely the light reflects into the observer's eye. Smaller values result in a larger bright spot from reflected light, while larger values result in a smaller and tighter spot.
@return (diffuse brightness, specular brightness, attenuation)
 */
vec3 los_blinn_phong(in vec3 lv, in vec3 ev, in vec3 ld, in vec4 eq, in vec3 normal, in float shininess)
{
   //Compute the distance of the light vector.
   float dist = length(lv);
   //Compute the inverse of the attenuation.
   float attinv = dot(eq.yzw, vec3(1.0, dist, dist * dist));
   //Is the distance is extremely close, or the inverse attenuation is very small?
   if(dist < 0.01 || attinv < 0.01) {
      //Yes, exit early with all zeroes.
      return vec3(0.0);
   }
   //Compute the unit vector of the light vector.
   vec3 lvn = normalize(lv);
   //Compute the diffuse brightness as: cos(angle between the surface normal and the light vector).
   float diff = dot(normal, lvn);
   //Is the diffuse brightness negative? (This indicates that the light source is behind surface.)
   if(diff <= 0.0) {
      //Yes, exit early with (0, 0, attenuation).
      return vec3(0, 0.0, 1.0 / attinv);
   }
   //Compute the reflective strength.
   //hv is the ideal normal, this is normal for the surface to achieve perfect reflection from the light vector to the eye vector.
   vec3 hv = normalize(lv) + normalize(ev);
   //ndh is the reflective strength as: cos(angle between the surface normal, and the ideal reflective normal.
   float ndh = dot(normal, normalize(hv));
   //Compute specular brightness as: ndh ^ shininess Note: ndh is clamped to 0 to prevent oddities from negative values.
   float spec = pow(max(0.0, ndh), shininess);

   //Return the results.
   return vec3(diff, spec, 1.0 / attinv);
}

My tired mind couldn't infer the intent in the last couple of lines in of the cel shading function, so pardon the ??? markers.
{l Code}: {l Select All Code}
/**
Applies a cel-shading to a colour value based off of the material's colour value and the diffuse and specular lighting.
@param material The RGBA color values of the surface material.
@param diff The RGBA colour values of the diffuse light source.
@param spec The RGBA colour values of the specular light source.
@param t1 The cel shading map.
@return The output RGB colour after applying the cel shading effect.
 */
vec3 los_cel_shading_skin(in vec4 material, in vec4 diff, in vec4 spec, in sampler2D t1)
{
   //Compute the diffuse brightness value.
   float diff_v = dot(diff.rgb, vec3(0.3, 0.59, 0.11));
   //Compute the specular brightness value.
   float spec_v = dot(spec.rgb, vec3(0.3, 0.59, 0.11));
   //Compute the cel shaded brightness.
   float cel_v = 2.0 * texture2D(t1, vec2(diff_v, spec_v)).r;
   //Get the combined lighting value, clamped to a 0.001 minimum.
   vec3 lit = max(vec3(0.001), (diff + spec).rgb);
   //Compute the brightness of the combined lighting.
   float lit_v = max(0.00001, dot(lit, vec3(0.3, 0.59, 0.11)));
   //Compute the material colour under the combined lighting and then scale that by cel_v/lit_v
   vec3 mat = material.rgb * lit * (cel_v / lit_v);
   //Get the brightest and darkest RGB channel values.
   float mat_v = max(max(mat.r, mat.g), mat.b);
   float mat_m = min(min(mat.r, mat.g), mat.b);
   //Get the saturation value (1 = full saturation, 0 = no saturation).
   float mat_s = 1.0 - mat_m / mat_v;
   //Get the smallest of 1/satuartion and 2 - cel_v ???
   float mult = min(1.0 / mat_s, mix(2.0, 1.0, cel_v));
   //???
   return max(vec3(0.0), vec3(mat_v) + (mat - vec3(mat_v)) * mult);
}


The fragment shader in "data/lipsofsuna/character/celshading/diffskin1.frag" is what calls los_cell_shading_skin().

LiamM32 {l Wrote}:Another observation I have noticed is that some objects don't have any ambient light. The hair is totally black on the unlit side; a stark contrast from the skin and everything else.


Looking at the hair fragment shader in "data/lipsofsuna/character/celshading/hair1.frag", it appears that it fiddles with the colour value and specular light value before calling los_cel_shading(). This might be resulting in a darker colour and specular light values, which is then further exacerbated by you cel shading table discarding specular light, but the cel shading function still having side effects from specular. That said, it's also possible that the ambient light isn't connected to the hair fragment shader, which will result in what you're describing.
User avatar
xenodora
 
Posts: 27
Joined: 05 Jun 2016, 15:11

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 17 Jul 2017, 22:13

farrer {l Wrote}:You should look at where in the code the RenderSystem is created. On a quick search, at render.cpp:
...
It's using the default OpenGL, which isn't GL3+. You should change that accordingly, if I do remember it on Ogre 1.10:
...

I changed render.cpp as you suggested. Here it is so that you can verify that I did it correctly.
render.cpp
(26.36 KiB) Downloaded 11 times

It compiles fine with these changes, but segfaults immediately when I try to run it. Can it be caused by the old GLSL version (as GLSL 1.30 is the equivelent of OpenGL 3.0)?
Here is the gdb backtrace.
{l Code}: {l Select All Code}
(gdb) bt
#0  0x00007ffff63ce509 in Ogre::Root::shutdown() () from /usr/lib/libOgreMain.so.1.10.5
#1  0x000000000049d1ff in LIRenRender::deinit (this=0x874890) at ../src/lipsofsuna/render/internal/render.cpp:141
#2  0x000000000046e91a in liren_render_free (self=0x874890) at ../src/lipsofsuna/render/render.cpp:125
#3  0x000000000046e7a7 in liren_render_new (paths=0x83c260, mode=0x7fffffffd6c0) at ../src/lipsofsuna/render/render.cpp:80
#4  0x000000000053d245 in liext_graphics_new (program=0x83c0c0) at ../src/lipsofsuna/extension/graphics/ext-module.c:71
#5  0x00000000004274f7 in limai_program_insert_extension (self=0x83c0c0, name=0x400095e0 "graphics")
    at ../src/lipsofsuna/main/main-program.c:404
#6  0x00000000004638bc in Program_load_extension (args=0x7fffffffd7a0) at ../src/lipsofsuna/script/script-program.c:100
#7  0x0000000000460ef3 in liscr_marshal_CLASS (lua=0x40000378) at ../src/lipsofsuna/script/script-args.c:1131
#8  0x00007ffff796d316 in ?? () from /usr/lib/libluajit-5.1.so.2
#9  0x0000000000466267 in private_lua_require_load (lua=0x40000378, root=0x83c380 "/home/liam/src/lipsofsuna/data",
    path=0x874710 "system/light") at ../src/lipsofsuna/script/script.c:472
#10 0x00000000004660ea in private_lua_require (lua=0x40000378) at ../src/lipsofsuna/script/script.c:428
#11 0x00007ffff796d316 in ?? () from /usr/lib/libluajit-5.1.so.2                                                                     
#12 0x0000000000466267 in private_lua_require_load (lua=0x40000378, root=0x83c3f0 "/home/liam/src/lipsofsuna/data/lipsofsuna",       
    path=0x874470 "core/client/lighting") at ../src/lipsofsuna/script/script.c:472                                                   
#13 0x00000000004660c4 in private_lua_require (lua=0x40000378) at ../src/lipsofsuna/script/script.c:427                               
#14 0x00007ffff796d316 in ?? () from /usr/lib/libluajit-5.1.so.2                                                                     
#15 0x0000000000466267 in private_lua_require_load (lua=0x40000378, root=0x83c3f0 "/home/liam/src/lipsofsuna/data/lipsofsuna",       
    path=0x8743d0 "core/client/client") at ../src/lipsofsuna/script/script.c:472                                                     
#16 0x00000000004660c4 in private_lua_require (lua=0x40000378) at ../src/lipsofsuna/script/script.c:427                               
#17 0x00007ffff796d316 in ?? () from /usr/lib/libluajit-5.1.so.2                                                                     
#18 0x0000000000466267 in private_lua_require_load (lua=0x40000378, root=0x83c3f0 "/home/liam/src/lipsofsuna/data/lipsofsuna",       
    path=0x873ff0 "core/client/bindings") at ../src/lipsofsuna/script/script.c:472                                                   
#19 0x00000000004660c4 in private_lua_require (lua=0x40000378) at ../src/lipsofsuna/script/script.c:427                               
#20 0x00007ffff796d316 in ?? () from /usr/lib/libluajit-5.1.so.2                                                                     
#21 0x0000000000466267 in private_lua_require_load (lua=0x40000378, root=0x83c3f0 "/home/liam/src/lipsofsuna/data/lipsofsuna",       
    path=0x873520 "core/client/init") at ../src/lipsofsuna/script/script.c:472                                                       
#22 0x00000000004660c4 in private_lua_require (lua=0x40000378) at ../src/lipsofsuna/script/script.c:427                               
#23 0x00007ffff796d316 in ?? () from /usr/lib/libluajit-5.1.so.2                                                                     
#24 0x00007ffff79b2fe0 in lua_pcall () from /usr/lib/libluajit-5.1.so.2                                                               
#25 0x0000000000465d19 in private_exec_script (self=0x83d6a0) at ../src/lipsofsuna/script/script.c:326                               
#26 0x0000000000465b63 in liscr_script_load_file (self=0x83d6a0, path=0x576dee "main",                                               
    path_mod=0x83c3f0 "/home/liam/src/lipsofsuna/data/lipsofsuna", path_core=0x83c380 "/home/liam/src/lipsofsuna/data")               
    at ../src/lipsofsuna/script/script.c:252                                                                                         
#27 0x0000000000427049 in limai_program_execute_script (self=0x83c0c0, file=0x576dee "main")                                         
    at ../src/lipsofsuna/main/main-program.c:227
#28 0x00000000004288ea in main (argc=1, argv=0x7fffffffde88) at ../src/lipsofsuna/main/main.c:106



Thank you too Xenodora. I am on my laptop right now, away for the weekend. I will analyse what you posted when I get back to my desktop.

I also want to make the shaders use per-fragment lighting.


I started this topic on the Urho3D forums to ask how OpenGL performance compares to OGRE. They seemed to think that it would probably be slightly better. It is likely worth it to remake Lips of Suna with Urho.
Last edited by LiamM32 on 18 Jul 2017, 00:18, edited 1 time in total.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby farrer » 18 Jul 2017, 00:01

From the backtrace you posted it seems that Ogre couldn't be initialized and LoS is calling it to shutdown (the segfault is in the shutdown, probably doing from trying to free something that isn't yet created):

{l Code}: {l Select All Code}
   /* Initialize the backend. */
   if (!self->init (mode))
   {
      liren_render_free (self);
      return NULL;
   }


Does Ogre.log have any information or error on the initialization process?

Edit: Got some time and made a quick test to initialize Ogre 1.10 with GL3+, the correct string to use should be:
{l Code}: {l Select All Code}
"OpenGL 3+ Rendering Subsystem"
User avatar
farrer
 
Posts: 67
Joined: 24 Feb 2014, 21:00

Who is online

Users browsing this forum: No registered users and 1 guest