theopenspaceprogramarchive/urho-osp

Open Space Program in Urho3D

urho-osp's Issues

[ Request ] Add the Kraken

Self explanatory.

Add build instructions for Windows

Bless their souls.

Get rid of magic numbers

@Causeless pointed out a few examples on Discord:

https://github.com/TheOpenSpaceProgram/urho-osp/blob/23d1e061026d0cf6dd911ebd26a4ecd534eef670/src/PlanetWrenderer.cpp#L583-L584

[12:28] Causeless: magic numbers no good 🙁

https://github.com/TheOpenSpaceProgram/urho-osp/blob/23d1e061026d0cf6dd911ebd26a4ecd534eef670/src/PlanetWrenderer.cpp#L594-L598

[12:29] Causeless: 5? 0.2?
[12:30] Causeless: seems that the culling for back-facing tris is too aggressive too
[12:30] Causeless: I guess 5 here is the max subdivision depth

compiling on debian

Hi
I am trying to compile OSP on a debian system.
Building and installing Urho3d was succesfull.

Then during the build of urho-osp I get a number of errors. First type is with constexpr, and this can be removed by removing constexpr from the header files.
Any ideas what would be the correct solution here?

In file included from /home/flindt/OSP/urho-osp/src/Machines/../OspUniverse.h:10, from /home/flindt/OSP/urho-osp/src/Machines/MachineRocket.h:16, from /home/flindt/OSP/urho-osp/src/OspUniverse.cpp:16: /home/flindt/OSP/urho-osp/src/Machines/../Terrain/PlanetWrenderer.h:388:16: error: redeclaration ‘constexpr bool osp::PlanetWrenderer::is_ready() const’ differs in ‘constexpr’ from previous declaration constexpr bool PlanetWrenderer::is_ready() const ^~~~~~~~~~~~~~~ /home/flindt/OSP/urho-osp/src/Machines/../Terrain/PlanetWrenderer.h:279:20: note: previous declaration ‘bool osp::PlanetWrenderer::is_ready() const’ constexpr bool is_ready() const; ^~~~~~~~

Then if I continue the build with a few edited files, removing "constexpr", I get another error.

[ 5%] Building CXX object src/CMakeFiles/OSP.dir/main.cpp.o /home/flindt/OSP/urho-osp/src/main.cpp: In member function ‘virtual void osp::OSPApplication::Start()’: /home/flindt/OSP/urho-osp/src/main.cpp:161:9: error: ‘RegisterObject’ was not declared in this scope RegisterObject<OspUniverse>(scriptEngine, "OspUniverse"); ^~~~~~~~~~~~~~ /home/flindt/OSP/urho-osp/src/main.cpp:161:9: note: suggested alternative: ‘register_t’ RegisterObject<OspUniverse>(scriptEngine, "OspUniverse"); ^~~~~~~~~~~~~~ register_t

I am using gcc version 8.3.0.

PlanetWren Issues

Malformed triangles, resulting in edges going through the centre of the sphere:

SubTriangle* children = get_triangle(tri->m_children);

set_neighbors(children[0], tri->m_children + 3, tri->m_neighbors[1], tri->m_neighbors[2]);
set_neighbors(children[1], tri->m_neighbors[0], tri->m_children + 3, tri->m_neighbors[2]);
set_neighbors(children[2], tri->m_neighbors[0], tri->m_neighbors[1], tri->m_children + 3);
set_neighbors(children[3], tri->m_children + 0, tri->m_children + 1, tri->m_children + 2);

This code uses children[1] - [3] without checking that they exist, meaning it writes beyond the end of the triangles array. tri->m_children + 3 is inconsistent: why are m_neighbors using array indexing and m_children using pointer arithmetic? It'd make more sense if these all use [], i.e tri->m_children[3].

inline uint8_t PlanetWrenderer::neighboor_index(SubTriangle& tri, trindex lookingFor)
{
    if (tri.m_neighbors[0] == lookingFor)
        return 0;
    else if (tri.m_neighbors[1] == lookingFor)
        return 1;
    else if (tri.m_neighbors[2] == lookingFor)
        return 2;
    // this means there's an error
    //printf("Errrrorr \n");
    return 255;
}

A loop would be a little cleaner here (and should be unrolled by the compiler anyways), but that aside, why return 255? This should be an assert.