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