Rendering issue, lore, Unity

[aybe]

Nice surprise that your project is on shikadi's modding wiki (I am the one who started the topic actually).

The binary release does not work:

Level is drawn but incorrectly :(

Been trying to run it from the sources but ended up with the following:

---

I haven't really tried to find out the causes yet, thought I'd come over and ask you !

Thanks

[movAX13h]

Hi! Yes, I added the link to the wiki yesterday. Did you do the reverse engineering of rnc? Looks like some shaders failed to compile. Can you post the content of the logfile? It should be data/hioctane/logs.txt

[movAX13h]

I should mention that the editor currently suffers from fps drops every 4 seconds. That's when the terrain and building morphs are active. I had no time to optimize geometry updates yet. Maybe it needs some refactoring. The main problem is the sprite atlas texture which makes it impossible to share vertices of neighbor cells of the terrain mesh - each cell needs to have 4 UVs which are not related to the neighbor cell UVs - because we only have 1 texture. So for terrain morphs this means to modify 4 vertices per cell corner (1 vertex per touching cell). Currently I'm brutally updating all vertices of the terrain each frame and regenerating all buildings depending on the terrain below.

If you want to get into the code, feel free to ask anything anytime.

[aybe]

Found the error !!!

I remember a while ago that AMD (here I have an HD7850) has a buggy OpenGL and you get all sort of surprises with OpenTK; plugged my screen to the integrated Intel HD4600 and it works:

(FPS is misleading, actually it's ~40 and on overall my PC is slower)

I've unearthed the 3 years old thread I've asked at AMD that nobody bothered to answer, I guess it should be more or less the same kind of issue though I didn't see any explicit layout in your shaders:

https://community.amd.com/thread/168824

(honestly I don't have the guts to fire up CodeXL again to try find the cause, at least today 😫 )

EDIT:

been trying to fix it up but no luck, either those frame analyzers only support DirectX or they crash at best, the only thing I could see in CodeXL is like above, uniforms are swapped.

seems like layout (std140) ... could fix it but for what I tried then the shader does not work (needs major overhaul I guess) (also my OGL skills are rusty, it's been years I've stopped using it) (probability that I'll fix it is around 0% :) )

---

RNC

I've been using the source code out there I guess of dernc.exe, simply rebuilt a DLL which I call from C#.

I am going to fix and finalize the project and make a repo, basically it'll be a C# RNCStream which simply unpacks if it's compressed.

---

For the editor, yes I have a few questions but I'll come back later today, have to finish something now ...

[movAX13h]

Cool, glad it works finally. Iirc, the game uses 3 variations of RNC. Srtuss knows all the details since he extracted all assets and I hope he will write something up soon.

Still, if it does not work, the logfile should contain all information needed to fix the bug.

[aybe]

Here's the unpacker: https://github.com/aybe/RNCUnpacker/releases

Tested quickly and works as expected, let me know otherwise. Basically you have an RNCStream you'll use like: new RNCStream(File.OpenRead("abc.txt"));. If input was packed it has been unpacked first.

---

For the editor,

My biggest complain about the code is that it's poorly written, you've mixed low-level types with your view and model logics:

• very hard to follow, unrelated things happen in same scope
• weird dependencies (game types depend on WinForms)
• lots of unused stuff like in shaders you check but don't throw (have to put breakpoints to figure out)
• will be very difficult to expand in the end, not sure if it's worth the time

Actually I've been working on a remake of the game using Unity but was stuck in RE-ing levels ... now you geniuses did it ! My plan is to extract game types from your code until I have a 3D level working in Unity. Now if you're interested, a level-editor could be done using Unity (personally I'm more interested by a modern engine than an editor); with less hassle such as OGL stuff and so on. Yesterday I've extracted and rewrote the types from your code, maybe today or tomorrow I will give it a try and see if I did things well.

Cheers !

[movAX13h]

Sure, code can always be cleaner. Srtuss is working on a modern version of the game in his own engine written in c++. He has not published anything yet but I hope he will soon. ( http://srtuss.net/stuff/hioctane/better_sound.mp4 , http://srtuss.net/stuff/hioctane/boost.mp4 )

[aybe]

That's really cool ! Not sure what to do now then ...

[movAX13h]

A simple level editor would be nice to have. I dont know if srtuss will finish the game. It's been a while since he worked on it.

The project is not that big so refactoring should be easy if required. The game types dont depend on winforms. I just have not cleaned up after I copied the code from the inspector project. The gui is using winforms to be able to show native alert messages box but it is not necessary and can be removed.

The engine is my third iteration and I find it very convenient. If anything bad happens, it should be in the log file. Some classes of the editor don't check the Ready boolean which results in wrong visuals but the error is still reported in the log file. In most cases it will show a messagebox right after something failed to load and then close the application.

The editor can already be used to modify the terrain of the original levels and save them back. With the inspector you can modify entries of the entities table bytewise and write them back to the level files and play them in the original game.

Anyway I put my code here so that it does not rot on my harddisk. I'm happy if you can use the information about the level files - it took quite some time to identify all entity types, the group-, trigger- and morph-mechanics.

Btw., I've contacted the original authors of the game and asked them how the level editor was made for the original game after I found traces of a level editor in the hioctane binary - but I'm still not sure how it was structured exactly: http://thrill-project.com/archiv/coding/hioctane/HiOctane_corr.pdf

[movAX13h]

Not sure how you want to do a level editor for the original level files in Unity and I don't think it would be much easier to do. I've already implemented all of the basics like geometry generation, ultrafast 'raycasts' optimized for the Hi-Octane universe, terrain modifying and a UI system ... all of that you'll have to do in Unity too. If you want to stick to the original level data files, you can not use the Unity terrain tools or any of the fancy stuff Unity offers on the editor side.

If you want to implement the game in Unity, I can help if you want but it would be more of an exercise than a challenge.

[aybe]

Thanks for the PDF, going to read it !

I might give it a try another day but for today the videos got me ...

---

Actually I've been working for quite some time on a modern engine for Wipeout 1/2/3/64, most reverse engineering is done and many things implemented, but I encountered a few overall architecture problems such as, how to ship the game without the original or modified content (for legal issues) ?

The other bigger issue was the fact that data as it is definitely requires a level editor, e.g. PRMs are collection of models, in which unrelated things are packed and I haven't found any kind of flags to separate this mess.

Like for the rescue ship, using a level editor with a mouse would allow very easily to create distinct parts of the ship requiring different materials (body, lights, etc ...). There are definitely secrets in the executable, and low-level tricks that simply can't be applied on a modern environment (e.g. increment a pointer to animate a texture, pre-compiled PSX addresses as I've found, etc ...).

That basically led me, to sketch out an asset system that should be simple enough but powerful in order to be able to shape game data as I want but at the same time not reference it. And also separate concerns, this obviously lengthens the code but if something's wrong you can relatively easily switch your strategy.

I'll stop here, I guess you get the point ...

These are quite old videos, https://www.youtube.com/playlist?list=PLVfrRhK9CjLh3aFKtmLe_bFUfokDwnlST

Also bigsnake from BallisticNG helped me out: https://www.youtube.com/watch?v=SWBGR6oDxQo But the problem is, he came in, dropped tons of messy code then disappeared, you'll agree that the sim is much better than mine was, but it was a dilemma on whether to keep it or not (at the time I started a new code base and figured out Wipeout 3 all myself (and did not re-use it)).

---

I can imagine you spent a lot of time, in figuring it out ! I stopped at the track blocks, trying to understand how they worked but failed.

With Wipeout, there was http://phoboslab.org/wipeout/ from which I started, but then I figured out much much more and the worse was WO3 were track edges were on a separate weird file I debugged non-stop in a 12 hour session ... I'd say +90% of game data is understood now.

---

I suggested Unity because I've been using it for around 3 years and that's what I use regularly. While there are disadvantages there are also many advantages especially regarding low-level plumbing.

But I understand your position in wanting to stick with OpenTK and regarding the amount of code you've already produced.

What I'll do over the next days is spend time with your code base and at the same time with my project, and we'll see whether our opinions converge or diverge by then :)

[movAX13h]

Good work on wipeout! Regarding license I think you could still release and even sell the game on steam without data files and add instructions on how add them if they are not free. For Hi-Octane I would not hesitate to add them directly because they are available all over the internet for free.

---

For the game srtuss is/was working on, we wanted to remake all crafts like this (other colors though) but we don't have all of the crafts yet:

http://srtuss.net/stuff/hioctane/new_jet.mp4

---

I've been using Unity a lot too in the last couple of years and if I wanted to remake the game I'd probably use Unity too because I don't want to implement secure/safe/fast network code and all the lighting/octree/culling stuff myself. For an editor, none of these are required.

---

Ok cool!

[aybe]

Thanks.

The craft looks really great even with these colors!!! Seen it already on your site as well as other cool things!

Really? I mean HO is owned by Electronic Arts IIRC, I'd rather push people to provide it by themselves.

Anyway you re right Unity is not vital for an editor unless you simply reuse it as such :) The problem with OGL is that whatever you need you have to code it such as a list box etc... And you know the devil is in the details, you'd waste lot of time for something that simply you need for a few things. But I agree that unity is a pain in the ass with its bugs , that bastard C style API and immediate GUI.

Had another look at your editor but failed to get that shader fixed over here, I will take another look tomorrow.

Cheers!

[aybe]

Just had another look,

I think the problem is as follows:

You've written a 'one-do-it-all savvy shader' which while smart does not work well on all environments. By commenting out all those defines, the result is better though still not correct (but trying on a previously working Intel HD4600 now it looks broken as below).

I'm afraid there's a bigger picture that I haven't figured out on why it looks like this, and honestly, I won't make another attempt in trying to figure it out (not a funny task and virtually the problem does not exist on your side).

I would suggest that you get a clear/stable interface on your shader, or maybe you'll pinpoint the issue I didn't see instantly.

(texture shader)

#version 410

precision highp float;

uniform mat4 model;
uniform mat4 modelView;
uniform mat4 modelViewProjection;
uniform mat4 shadowViewProjection;
uniform vec4 color;

in vec3 in_position;
in vec3 in_normal;
in vec2 in_texcoord;

out vec3 vn;
out vec2 UV;
out vec3 v;
out vec3 pos;
out vec3 shadowPos;

void main(void)
{
    pos = in_position;
    v = vec3(modelView * vec4(in_position, 1.0));

    //vn = normalize(model * vec4(in_normal, 0.0)).xyz;

    //L = -lightDirection;//normalize(lightPosition - v);

    UV = in_texcoord;

    shadowPos = (shadowViewProjection * vec4(in_position, 1.0)).xyz;

    gl_Position = modelViewProjection * vec4(in_position, 1.0);
}

#version 410

precision highp float;

uniform mat4 model;
uniform vec3 lightDirection;
uniform vec4 color;
uniform float opacity;
uniform float grayscale;
uniform float wireframe;
uniform sampler2D colorMap;
uniform sampler2D normalMap;
uniform sampler2D shadowMap;

in vec3 shadowPos;
in vec2 UV;
in vec3 vn;
in vec3 v;
in vec3 pos;

out vec4 out_color;

void main(void)
{

    vec3 ambient = vec3(0.4);
    vec3 lightSpecularColor = vec3(1.0);
    float specFalloff = 30.0;

    vec3 normal = vec3(0.0, 1.0, 0.0);

    normal = vn;

    //normal = 2.0 * texture2D(normalMap, UV).rgb - 1.0;

    vec3 N = normalize(model * vec4(normal, 0.0)).xyz;
    vec3 texel = color.rgb;

    texel = texture2D(colorMap, UV).rgb;
    texel = mix(texel, color.rgb, color.a);

    if (grayscale > 0.01)
    {
        float m = (texel.r + texel.g + texel.b) * 0.33333333;
        texel = mix(texel, vec3(m), grayscale);
    }

    //out_color.rgb = texel; out_color.a = 1.0; return;

    float NdotL = dot(N, -lightDirection);

    if (NdotL > 0.0)
    {
        vec3 Reflected = normalize(reflect(lightDirection, N));
        vec3 Eye = normalize(-v);

        vec3 diffuse = NdotL * vec3(1.0);
        vec3 specular = pow(max(dot(Reflected, Eye), 0.0), specFalloff) * lightSpecularColor;
        out_color = vec4((ambient + diffuse + specular) * texel, opacity);
    }
    else
    {
        out_color = vec4(ambient * texel, opacity);
    }

    out_color = clamp(out_color, vec4(0.0), vec4(1.0));

    if (wireframe > 0)
    {
        float d = smoothstep(30.0, 20.0, length(v));

        float onLine = d * wireframe * max(
                            smoothstep(0.04, 0.0, abs(fract(pos.x+0.5)-0.5)),
                            smoothstep(0.04, 0.0, abs(fract(pos.z+0.5)-0.5)) );

        out_color = mix(out_color, vec4(1.0, 1.0, 1.0, 1.0), max(0, onLine - 0.5));
    }

    vec3 sp = shadowPos;
    sp.z -= 0.001;
    if (texture2D(shadowMap, sp.xy).z < sp.z) out_color.rgb *= 0.8;
}

(posting this as comment because it does not really fix the issue)

(btw my initial issue seems to have been fixed somehow because I tried again and it doesn't happen no matter how I scramble the uniforms)

[movAX13h]

If you could please post the log file I could easily help you.

[aybe]

Here's the log, on the original source as well as when I modified it:

[LOGS REMOVED for readability]

They are identical (kdiff) ... the problem lies in how your are doing things, since you do little to no checking they are identical even though the shaders have been modified !

EDIT:

Narrowed the problem a bit, the original source will work as screenshot above, if I simply comment this in texture.vs:

    #if USE_VERTEX_NORMALS
    //vn = normalize(model * vec4(in_normal, 0.0)).xyz;
    #endif

[movAX13h]

Hmm, ok thanks! I'm quite sure it is just one single small problem. I will see and check if I can reproduce it on other machines/gpus.

[aybe]

Ok !

[aybe]

Just added a tiny feature to the editor : https://github.com/aybe/HiOctaneTools/commits/master But I'm hesitant to further improve it because it's a pain with Forms ... Why didn't you pick WPF because it would have been much easier ? :)

I've been trying to get something up within Unity and hit a wall, did you know that meshes cannot have more than 64K vertices ? That's so baffling ... I'm looking for a solution about this. Any ideas on how hard would it be to get tile infos in the level inspector ? (the track exceeds that + the UV problem you mentioned earlier)

I already have the models up and running !

Here a few pics of the pseudo editor I used for Wipeout:

Alright I'm done for today, see you!

[movAX13h]

Hi! Thanks for the changes you made to the inspector. Feel free to convert it to WPF. I think, when I started the Inspector, I was not sure what it would be in the end. Anyway, it is just a PictureBox and some tables! Now since everything is known in the entities table, the tool has lost its original main purpose of helping to idenfity things ... but it still serves better than a plaintext file containing numbers and descriptions I think.

---

What exactly do you mean with 'tile infos'? The map on the left shows the bytes of the map (each cell has 12 bytes). For convenience I put in byte -1 and -2 (=default) where -1 is the height of the cells (composed of 2 bytes) and -2 is a complete render of the textures specified by the texture ID (2 bytes iirc) respectively the floor texture of the building column at that position (building columns are indicated by negative texture IDs).

---

Yes, I stumbled over that limit when I did some mesh generation (for example https://www.youtube.com/watch?v=ARJlOoukskQ). Since everything in Hi-Octane is tilebased it might be an option to represent the whole world in columns instead of larger junks of meshes. The maximum size of a map is 256x160 = 40.960 cells. It's important to know that the terrain and the buildings can change during a game. The terrain can morph areas (mirrored from other regions of the map, triggered by a player hitbox, triggered by a timer or permanently morphing) and the buildings can be removed by a trigger (in most cases it is a rocket trigger). When the terrain morphs, the buildings on top of it are adapting to the new height of the terrain which sometimes also changes the shape of a building and parts of neighboring cells (like 2 vertices that touch a morphing cell).

I'm not really sure if there is a better solution facing the limit. Someone probably has made a dynamic mesh class that takes care of this problem. The obvious optimization here is to only mesh-update changed (affected by morphs or triggers) cells.

---

Here's a screenshot of the reworked truck in unity :)

See you!

[aybe]

Was having another last look for today actually !

The inspector does its job, it just needs a few additions.

By tile info I mean what you call cells which is more appropriate in fact, I was trying to figure out whether there's a way to strip out all the unused cells or better know their type. Then I could generate a mesh for the track, one for the walls and ignore what's unneeded.

But it seems that I'm gonna have to dive deep for this with eventually failing at the end :)

The irony with Unity is that looks like shiny but as you get to know it and the lack of documentation it's kind of crap, there are not many handy alternatives, UE4 rocks but it's C++ and development time is much longer.

That mesh generation video is really impressive btw !

Well I don't know what to do now, coz' each time you show me HD renders of models so I'm wondering whether you've already got something to unleash ! Common sense should push me back to continue the work on Wipeout but I thought maybe I could pull out something of HO in 2 weeks, but that sounds too optimistic by now.

Anyway, I'm going to continue study the inspector and maybe I'll get onto something; I'll let you know whenever I have something significant or discovered something.

Alright, good night mate, see you!

[movAX13h]

Hi, the truck and the other model you saw are the only ones we have ... sadly :) Your wipeout scenes look promising!

---

I had some time tonight and implemented the Hi-Octane map in Unity ... first I tried to have 1 game object per cell but it resulted in 20fps :) Now I'm generating cells in batches of customizable size. Each batch has one mesh. Not sure about the morphs though ... maybe you want to try it first :) Buildings are not in yet but the texture is properly loaded. The colors look so soft in Unity ... I don't like that but I guess it's just a lighting setting.

Everything is generated on game start from the level data files. If you prefer editor-side generation, feel free to make editor scripts.

Heres the project: [link removed] I've added some comments to the game specific classes.

That's what it should look like:

[aybe]

Thanks, this is great and I'm ready to focus on HO for this month, so I'll just pause Wipeout for now ! I'm pretty sure this will be beneficial because I'll have a fresher look on it ...

Started enhancing it, haven't done a lot yet but I got a solid free look camera up !

I have up my sleeve the usage of the game files themselves for pretty much everything beside sounds, instead of having to convert those; will focus on that next and also will integrate models. Then I'll take a look at the level-related issues.

Inviting you to my repo now !

[movAX13h]

Very nice! The camera works very well. I think I will finish the terrain and the buildings then. Do you have some experience with multiplayer network code in Unity?

Note: The project in your repo is not ready to play when freshly cloned. All script references are broken. I'm using Unity 5.5.1f1 by the way.

I think we should move away from this post here. Do you use slack or skype?

[aybe]

Been working on it actually !

Sorry but no experience with MP code at all ...

Not sure what's going with Unity, got exactly the same as you, re-opened it and seems to work now ... I guess it'll get on its feet over time.

Slack seems to be a good thing, didn't know about it ! just created https://hi-octane.slack.com/ (btw, no webcam nor mike for Skype anyway)

[aybe]

Almost there, lots of typing actually !

It'll be a one-liner to get a model:

        var data = new GameData(".data");
        var model = data.GetCraftModel(Craft, Team);
        var mesh = model.Mesh;

        var meshFilter = GetComponent<MeshFilter>();
        meshFilter.mesh = mesh;

        var meshRenderer = GetComponent<MeshRenderer>();
        meshRenderer.material = new Material(Shader.Find("Hi-Octane")) {mainTexture = model.Atlas.Texture};

I have an entry point which produces an atlas out of DAT/TAB, last task is to figure out their manual dimensions.

And I reused my approach in Wipeout which is IPolygon and Model types, simply emit polys and the model builds a mesh effectively abstracting all this mess.

Will post that tomorrow once it's clean, cheers !

[movAX13h]

Looks very convenient to work with! Seems like Slack didn't work for us :) Let's continue here.

[aybe]

Sorry, turned notifications off and totally forgot about it ... okay let's stay here, it's just simpler in the end.

Struggling quite a bit with the map but I'll get it done soon, actually I'm writing a level editor with picking and so on to help me identify all the data! I'll probably get back to you around this weekend hopefully !

(did quite a bit of coding but it's not yet ready for a commit)

[aybe]

Okayyyyy, still not there but getting closer ! Thought I was never going to see the light, all those relative offsets and so on lol...

Checkout MapViewer scene, it's still flat for now but there is cell hovering with info -> getting a decent cell editor should be feasible with the help of handles, actually I was stuck with dumb Unity things but now it's reactive as expected.

There are bunch of changes, the atlas is now totally generic, reading game atlases is too, etc ... too many things to remember but I guess you'll see the code is more friendly and more decoupled.

On my TODO list:

• implement height
• fix that damn UV bleeding once and for all with something like https://github.com/AlexSTV/uPaddingBleed
• implement the rest of the map

Could you do a quick recap on how things actually work ?

• columns, are these what's sitting on some cells ?
• entities, how do they work, i.e. morph source ?
• blocks, are these combinations of cubes to display in columns ?
• what are the things problematic/you didn't figure out ?
• you talked about some objects above cells should move, what was that ?

Well, I'll definitely look at your previous editor but a few text explanations are welcome 👍.

Cheers !

[movAX13h]

Sounds great! I've downloaded the project from your track branch but again all script and material references were broken when I loaded the scene. I've set everything manually but now it complains about missing RNCUnpacker.dll but it definitely is there ... I don't know ...

I've updated the readme of the project with my text explanations: https://github.com/movAX13h/HiOctaneTools#structures-and-concepts

[aybe]

Thanks a lot, way more than basic explanations :)

I will try digest that ASAP and see if I can come up with the best possible design to integrate all that (gonna be tricky). Problem is as we're adding stuff it becomes increasingly more difficult to make changes if it's not adapted to the problem, i.e. that Model + IPolygon stuff while working well and simply in Wipeout globally and HO 3D models, ended up bulky for the HO map (or I was in a rush).

Or maybe we should talk in general terms for the time being ? How would you shape a couple of types that'd be responsible in representing/updating the game ? A complex question, I agree...

---

Regarding Unity, it's a real piece of crap in some ways, over here I've simply abandoned the idea to press F5 for debugging in VS while it is playing, it will crash no matter what with access denied. It's been a while I'm planning for a complete Windows reinstall; it seems that as soon as you either update VS, Unity or associated plugins, the whole thing becomes unstable (I remember things worked well on a fresh setup). And testing that beta supporting C#6 side to side simply breaks the stable one, crashes very frequently.

It really reminds me of DOSBOX where I've submitted a rather nice fix for joysticks but it's never been merged, thing is 100's of devs contributed in their own way, no strict rules, code is unbelivably messy where one just dumps his load, if it breaks something they hack it in some way just enough so that it works again.

Unity is just like that, tons of devs, no real structure (see their decompiled stuff when trying to understand how they did that menu and so on), poorest documentation ever and they rarely fix bugs, it's really all about the numbers and piling things up just like StackOverflow ... that said, it's still the simplest way to quickly craft something :)

---

In regards to your problem, it did that to me the first time I've synced that project, now it doesn't ... Still at some time it does reimport all assets and I get tons of errors, but if I play the game they all vanish ... and AFAIK an older version shouldn't open a more recent one but for some reasons it's working for you X)

[aybe]

Sorry, was all my fault !!

Added VS-specific ignores when I started the project, resulting in broken project for others (no meta).

Tested by downloading a zip file and no more broken references :)

(btw sync first, I've dropped track branch for now, let's keep things simple for now!)

[aybe]

Oh and by the way, yesterday I've fixed UV bleeding in a even simpler way that did not require anything particular like extra inset or painting the atlas:

• disabled AA (should be a post effect)
• disabled mip-map on atlas (obvious)
• disabled mip-map on atlas images (the real culprit)

[aybe]

Also I've added what I've found about implementing the music

They use SoundFont v1 SBK which unfortunately is not supported anymore and while trying to convert to supported v2 SF2, playing an XMI is pure silence. (you can drop MUSIC.DAT on xmplay and it will play, just add a sound bank first)

I was thinking maybe using fluidsynth or something like it would allow to render music with as many soundfonts as we'd want, if that fails I still have my P200MMX with an SBAWE I could record from :) (IMO the best music experience since that SBK is specifically targeting it, see the youtube link in the folder)

Now there's PSX as well, and for that I've already got my own Isobuster-like C# library I've had to develop for Wipeout, it can read any type of sector properly (e.g. XA M2F2 for videos), so getting CDDA will be simply a matter of minutes.

Okay this is more part of the cake topping than anything else actually...

[movAX13h]

I still get the error about the missing dll. Is it depending on another dll maybe? I think we should implement everything in C#. I've already translated the source code of the RNCDecoder but I could not get it working.

The game itself is very simple after everything is set-up properly.

1. The terrain and buildings (columns) can be treated as one unit where only collision detection is relevant during the game. For that to work, I suggest a robust mesh generator for map patches (a batch of cells where each cell has information about the column at its position) that generates the terrain + columns all in one mesh. The most difficult part here are the seams between the patches. Updates should be applied only to affected patches (when the terrain morphs).
2. The entities properly grouped so that groups can be activated/reactivated by triggers.
3. Lap counter using the checkpoint entities
4. The waypoint system for the NPCs (non-player crafts)

I think, after reading and understanding my explanations in the readme, a lot should become clearer to you.

[aybe]

No it doesn't depend on anything else ...

Okay, will look into all of your explanations in details (going to be long :)

Right now I'm struggling in what I thought would be a simple thing : add your editors so one doesn't have to ping-pong between solutions.

Trying to fix that and will look to that DLL issue as well ...

[aybe]

Okay I think I finally got it working .......... importing your project here and fixing RNC.

(very boring I thought I'd spend the afternoon deciphering your notes)

Here's what I did with latest commit here:

• delete project locally
• clone again in GitHub app
• open Unity project - it reimports everything
• there's an error message I just ignore
• open C# project from Unity
• there will 1000s of errors (Nuget OpenTK), build solution to fetch package, this will fix all errors
• close VS
• close Unity
• open Unity
• open C# project from Unity
• all external projects are visible in solution
• in Unity scenes are working (btw if you see something then it's just another bug from Unity because indeed it used RNC dll)

Notes:

• resetting RNC DLL props ended up in Unity deleting x86 folder, weird ... anyways it's only 64-bit now
• so I was wondering does your Unity ver is the last 32-bit version 5.5.1f1 ? and therefore errors on this ?
• try update Unity to latest release 5.5.2f1 ? maybe that'll magically fix it

PS I've just updated DLLs by these built in Release mode I'd also suggest you try re-install VS2015 c++ redist : https://www.microsoft.com/en-US/download/details.aspx?id=53587

I hope this procedure will fix it up for you, lol !

[aybe]

I've just tested the procedure again with the latest commit for the sake of it: everything works properly and even that error message is gone.

That said, going to have a look at your docs now !

[movAX13h]

Nice, now it works! I get the outlines and the details about the cell.

[aybe]

Great !

Been reading your docs, the beginning is rather easy but then it ends up really complex !

So what I was thinking is that we should sit down and sketch up how all that should end up, i.e. IMO no point in piling up stuff such as an editor on the current base. Currently I really have no idea on how to do that, been thinking about a voxel-like approach but I really don't know.

I mean we really need to know all the variables to account for, coding itself is not really a big issue once we mostly know how the result will be; OTOH adding this and this and this by incrementally upgrading sounds fishy to me, so this is my next objective : what system to build the level and update it accordingly ?

What you suggested is clearly the way to go, batches; but how can we expand that to account for columns, deformations and so on ?

Here are a few links that looks interesting, esp. the 1st demo:

https://www.assetstore.unity3d.com/en/#!/content/58423 https://forum.unity3d.com/threads/tutorial-procedural-meshes-and-voxel-terrain-c.198651/ https://github.com/mattatz/unity-voxel http://alexstv.com/index.php/posts/unity-voxel-block-tutorial-pt-6 https://github.com/voxelmetric/voxelmetric2/

I'm comfortable with C# but when it's about game programming patterns that's another story ! For now I'll continue looking at your docs and see if some idea emerge, was wondering there is a good online collaborative diagramming/brainstorm thing to throw notes at ...

I guess you get the point :)

[movAX13h]

I think the key is to let the batches contain all the geometry, which means, the floor quad and the column of all cells in it. The batches need a method to regenerate the mesh based on the gamestate (all current heights, taking tweens into account - in realtime). If this works properly, including clean batch-edges, the rest is game logic.

For the editor, I would stick to the "modes" concept. From the emails from Sean I got that they had modes for different tasks too.

I would refrain from turning AA off and ignore the texture problem for now since it will look differently with all columns, items, post processing and the angle of view of a player driving on the track.

The project will NOT grow since everything there is to do, is already defined precisely by the original game. No need for an enterprise solution.

A good and simple event system might be useful.

How about making the game in Unity first and the editor later?

[aybe]

Yes, I more or less ended thinking something like it, where I'd render 9x9x9 batches or more where the floor is baked as a cell, then some GetCellVerts() would be called at build then when necessary, and should account for game state. It was like confusing to think about it but since you confirm that I'll stop thinking and simply give it a try.

Ok for the rendering, and yes the editor should be based on the game, hence my hesitation to even look at it. Alright, probably going to take a look tonight/tomorrow.

btw I've got hold of an AWE32 environment with Vienna in a hope to convert that SBK to SF2, while it worked the playback on xmplay was only half good :( I guess I'll have some fun later re-plugging my old PC recording the music !

alright, talk to you soon