StuntsLegacyEngine

[Cas]

StuntsLegacyEngine
This first post will serve to keep at hand the information we're handling and to keep track of the status of the project.

The source code of this early version of the engine can be found at:
https://notabug.org/xlucas/sle

For compiling, FreeBasic can be found here:
https://freebasic.net

For creating track objects, you can get Blender from:
https://www.blender.org/

Currently, the engine can render objects at arbitrary positions and one can move around, define new objects with any rotation and place them. It accepts OBJ files. Ground and sky are not being drawn. It's easy, but better keep it clean for now. Some bugs present.

[Cas]

Alright. So now in more detail....

Source code and data files
You guys can get the source for this engine from the repository. I included a few data files, which so far are all text, so that should be fine, but I would like to be able to exchange data files more comfortably. I wonder if I can just edit the first post to add and remove attachments so that it's not accumulated, but just changed. Anyway, I'll try to find an optimal way to exchange this.

Getting the binaries
If you're going to be checking updates and modifying the source code, you can get FreeBasic and it'll be super simple. If you need me to pass the binaries, I can quickly get you the GNU/Linux 64bit executable, but for other platforms, it's pretty inconvenient for me to compile it. I have Wine on a portable computer and I have to pull it out, turn it on, copy the source to it, then compile it and then pass the binaries back. I could install Wine here, but it's like having two OSs running together all the time. I'd prefer to avoid it. But just let me know and I'll see what I can do.

Current status
If you've tried the previous engine and now you test this one, it will at first appear to you that I'm moving backwards   But behind the scenes, this engine is superior. I haven't yet turned on the sky and ground, but that's easy to do and I'm more concerned on other things. There's a config file where you can load a materials file, then several OBJ files that can make use of the materials in the first file. After that, you can place these objects anywhere on the map. With the arrows, plus A, S, D, W and PgUp/PgDn, you can move freely in the map. CTRL+D toggles debug information and [ and ] will change the distance-to-screen. Everything is in meters. The engine uses a coordinate system just like the one in Blender, with Z going vertically. I like it because it looks nice with the right-hand rule and makes more sense for an engine in which Z has phisically a different meaning from that of the other two dimensions. Visibility can be changed by modifying the source. It's set at 1200 meters.

Creating objects
You can use Blender to create object files. Going to File->Export will do the trick. Blender, by default, uses the same coordinate system and also works in meters. But!  I found that, at least the newest version of Blender, swaps Y and Z when saving OBJ files. This makes sense because other software will frequently use Z for depth, but I dislike that coordinate system as, to follow the right hand rule, you're forced to have Z grow towards the camera or otherwise Y grow down. Because of the swap in Blender, I decided to make my source code swap the coordinates back. In other words, work on your model as if the coordinates were exactly as shown in Blender. If your object appears rotated, though, let me know or check the LoadObj routine.

Materials
When you export an object in Blender, it will create two files: an OBJ file and a MTL file. You can load many OBJ files and many MTL files in the configuration, but it makes more sense to only load one material library. As you create materials in Blender, you're allowed to rename them. The name you give them will be passed to both the MTL and OBJ file. You could just append MTL files to one another to make one large material library. If you want to reuse a material you used for another object, just give it a similar colour while working in Blender, but make sure to assign it the same material name. When you load the OBJ file, the material will be loaded from the original MTL. Sounds confusing?  Just play around or ask me. I'll be making a new simpler format for this purpose soon.

Bugs
I'm having a problem since the previous engine (although now I understand part of it and before, I understood nothing). Even though the triangle clipping routine works, I get strange artifacts when triangles cross the camera plane. I am not totally sure if the problem ocurrs when the cross the zero plane or just the screen plane. I suspect the first. You'll see some glitches when this happens.

While the clipping routine does look OK and you can see how it works when you move the clipping distance forward, this clipping distance gives the impression of not being in proportion with the distance-to-screen. Could this be just an illusion?  No idea. But despite this, it is clear that rendering works better with the clipping routine active.

Some non-bugs are rather things to be done. Like, rotation can easily be optimised by creating a fixed matrix for each rendering iteration and then applying the same matrix to every object instead of repeating the calculation. Layers are not being taken into account, nor is pseudotransparency, like in Stunts, but that can be activated very easily. Same goes for the horizon.

[Cas]

Sorry about my absence here, but I have been working on the engine. It doesn't look like a lot, but I added horizon (which needs to be rewritten, as it's not perfect), I sorted out the clipping problems I had and I managed to optimize vertex rotation by creating a static matrix. The engine now can load .trk files (only the few elements that have already been recreated, of course) and I would like to make a configurable version so one can easily add and remove element bindings without having to edit the source.

With things working like they do now, I'm thinking the engine is more ready to become an X-Wing clone than a Stunts clone, but there it goes. Physics is going to be pretty hard to accomplish.

[Daniel3D]

Cas. I had something nagging in the back of my mind about something I've seen that I thought was interesting.
Today I found out wat it was.

Maybe I interesting:
Scala programming language.

I have a book (software engineering from scratch) on it where you can build an OS.
So as far as I understand, no dependencies.
(Not sure. I'm not a programmer)

[Cas]

Uhm!  I'm taking my first read about it!  From what I see after a very quick look, there are very good intentions here. It looks like the idea is to create a "Java done right". I am very critical of Java, so that sounds very interesting, but the thing I dislike the most about Java doesn't seem to be in the list of the things that Scala wants to change, ha, ha: the fact that Java forces you to use OOP. On the other hand, it does make several very good points. The code looks much cleaner in Scala and even though it's very OOP, I am kind of able to read it without getting lost (and it's my first look at it).

The lack of dependencies, which you mention, is surely true about Scala, because while I dislike Java, that one also depends only on a Java Virtual Machine and Scala can produce Java byte code, so it should share that property. If I have to mention one thing I do like about Java, it's precisely that and Scala has it too.

It says in the article that Scala is part-OOP/part-functional, but I don't see in the examples non-OOP code because apparently the person who wrote the article likes OOP. I'll continue to read more to have a deeper impression of it   Thanks!

And about the engine... I have to retake this and I'm feeling so lazy!  I've been thinking of simplifying the engine and make it load Stunts 3D shapes but make it work always on the ground, without banking (like a classic car engine). From there, I could begin working on the physics... acceleration, breaking, grip, gear torque, etc. Once I can really handle that, I can add the third dimension back again.

[Cas]

Alright. Back to the engine topic. I finally overcame my laziness and got my engine working in a different sense: I made it display the shapes from 3SH files. Now I've noticed that while they look very good, there are a few things that don't look the same and they won't unless I either modify the shapes or modify the engine, but while the latter would normally be the obvious, I have some reasons to prefer the former, so I ask for your opinions.

What happens is this. Stunts uses a culling and layering system that consists of three attributes:
- Culling flags (bits that tell you for each orientation whether you have to draw a primitive or not)
- Z bias (a bit that groups primitives by priority: first draw all primitives with Z-bias 0 and then all primitives with Z-bias 1)
- 2-sidedness (a bit that indicates a primitive can be seen from both sides; otherwise, they are only seen from the side where points run counter-clockwise)

My engine uses a different system and I thought it'd be compatible, but I've noticed exceptions. It goes like this:
- No culling flags
- Layer number (like Z-bias, but instead of going from 0 to 1, it goes from 0 to 3, so you can stack more polygons)
- 2-sidedness (same as Stunts)
- Automatic primitive ordering by how far their average vertex position is

And yes, automatic ordering manages to make culling flags unnecessary in almost every circumstance... Except when you want to draw line segments on top of a surface, like the barn door or the "Joe's" sign. Because segments have only one "side", the only way to tell whether they're on top or not is layering, but this makes these lines visible from the other side of the shape!  Solution?  Either implement culling flags or replace the segments with other primitives, such as thin rectangles, so that they can be one-sided.

Another problem comes because Stunts shapes were created taking culling flags into account. In some circumstances, the shape could've perfectly worked without the culling flags, but Stunts developers made some objects Z-biased and gave them culling flags because Stunts does not have an automatic primitive-ordering system. This is the case of gas tanks in front of a gas station. Solution?  Again, either implement culling flags or remove the Z-bias from those objects.

I don't feel like implementing culling flags because they would add up yet one more check and make the engine slower and more convoluted. Besides, when you're creating 3D shapes, being able to not thinking about culling directions makes design a lot more straightforward, in my opinion. But then, instead of creating a program that you can just place in Stunts directory and run it, probably the files will have to be converted first into another format and these details be taken into account.

Any opinions are welcome and if they add ideas, much more!

[Daniel3D]

Well. Conversion only goes for shape file's. So the original track pieces, scenery and cars.
The only have to be converted once.
So I don't really see a problem besides that I would have been cool to have used the original unaltered.

[Cas]

I'm still not 100% decided. Maybe I implement culling flags after all... but given that all new objects to come will not need those flags and cars don't appear to need them already.... I have doubts. Also, because Stunts cannot sort primitives, the developers had to split some objects into two or more models, to make sure that one is drawn before the other. By creating a new set (which could perfectly look almost identical to the original), we could just make them one thing each.

[Cas]

A look into some engine tests. I found a bug and fixed it. It's loading the shapes well. I haven't configured all shapes, but I can make a translation table and it will be easier. Track opcodes are a mess!  Why didn't they just ordered them all rotating counter-clockwise?  No!  Each track element has its particular distribution.

Anyway, I wanted to run this test with a few of the elements. In spite of the non-optimised routines, it runs very fast. I thought I was using heaps of memory, but no... Not even four megabytes. Not drawing the ground and the sky right now. I can add them quickly, but when not leveled, I'm doing something wrong with pitch and it doesn't match, so I have to rethink that part.

[Cas]

OK. Some more objects added, plus ground and sky. The engine still runs fast. There are a few concerns:
- Stunts shifts ramps automatically when on land slopes. I feel like it'd be better to create shapes for these. On the other hand, if somebody ever makes a new ramp style, it'd nice to have it automatically converted, but also prevents you from designing the way in which you would convert it
- Similarily, Stunts automatically changes the road material, so no extra shapes for dirt and ice. I could create new shapes for that or make a routine to do it automatically, like Stunts. For now, these things are not supported, so only paved roads
- Line segments sometimes are drawn when they're not supposed to because of the difference in culling systems. I can fix this by creating new designs
- No pitching or rolling with this ground and sky. While everything else rotates OK, I still don't have a good routine to rotate the ground and sky. It should be easy, but I have left it for the end.
- Windmills use an animation based on colours that change live. Those black regions are supposed to be sometimes transparent, sometimes brown. I can recreate this, but I prefer to do it in another way, so this is flexible and other objects can have animated things as well, so I'm not implementing what the original windmill would require. Instead, I will have to edit the windmill later.

[KyLiE]

Wow!  That looks amazing! I don't think I've ever seen so many Stunts objects rendered on screen at the same time!

[Daniel3D]

It looks amazing. Can't wait to drive test it.
(I know. I skip a few steps... Just excited by the looks)

[Cas]

With the high resolutions we have now (and this window is not even regular HD), small objects render well even relatively far and because computers are fast, there's no need to set the visibility so close. One thing I don't like very much is what road centre lines look like when they are far. Makes me think maybe there's still a reason to use lower detail shapes from a certain distance onwards. The current engine uses only one shape per element, but I could add that possibility later.

[Cas]

Still working on the rendering engine. It already works well (except I haven't made the ground/sky routine), but I was trying to tune it so that it renders Stunts original shapes as similar as possible. I guess I will have to give up a significant level of similarity to concentrate on what's important. I have no way to guess how the original engine interprets the Z-bias, but it's not the same as what I do, no matter what. With new shapes, there should be no artifacts, but inevitably, many will be present while using the original shapes... yet, at least, it will render the thing.

Later on, when there aren't other more important things to do first, I'll turn this into a Z-buffering renderer or at least, allow the option of using Z-buffering. I don't think of it as a priority now because it's a lot slower than what I'm doing and I'm sure Stunts didn't do it either. With Z-buffering, though, all culling problems would disappear.

As you can see in the picture, now materials can be changed freely. I also managed to convert ramps to horizontal. I have to test those to see if they align well, but it looks like they do.

[KyLiE]

Stunts never originally changed the ramp surface from paved even if the neighbouring track pieces were dirt or ice.  Is this a new feature that you are adding?