Vampire Flatshading Experimenting

[saimon69]

Well, you don't need a full port of Virtua Racing; just as the outrun "restoration" - that is starting to be really good on ST - you need something that "feels" and plays like Virtua Racing; i remember Simulcra moving a discrete amount of small polys; am not a coder but imo keeping geometries simple but with an impression of detail you can do decent stuff - in assembly of course; am thinking on how fast was Indy 500 running on a base Amiga 500

[skan]

Originally Posted by VladR

Awww, that's so cute

Just like Vampire fanbois.

Seriously, don't get me wrong. Nothing against the platform per se, but if you start doing SAGA/AMMX/Pamela/whatever-only stuff, that's no longer Amiga, pretty simple. If you're aiming for a Vamp killer app that's ok, but please don't tell me that's an Amiga game because.... well, it would not run on anything else than a Vamp!

That said, even if I'd never pay the amount of money needed for a V4 standalone right now, I'd be intrigued to see some nice Vampire-only action (that flat-shaded engine you mentioned would rock f.i.). As well as I'd like to see the same kind of philosophy applied to 060 and/or unexpanded 1200.

On topic: we're talking about Outrun port on AMIGA, not VAMPIRE anyway!

[Aladin]

? Amiga AGA isn't amiga? PC is only 8086 CGA?

[vulture]

VirtuaGP ran like that even on a "lowly" 68020@28mhz and 4mb fast ram, it was a wonder to behold!

[eXeler0]

Originally Posted by VladR

Yeah. That right there is going to be the problem with Virtua Racing. The environment polycount is all over the place. You know the spot with the animated rides on first track ? That's, like, 3x more polys than at other spots.


To drop to only 30 fps there, the other places would have to be running at around 60-75 fps. The arcade HW was pretty impressive - I don't recall how many CPUs it had, but it was a lot (it should be on wikipedia somewhere).


Especially on a single CPU - say like Vampire.


For sure, once my engine is ported to V4 and running, this will be one of the early tests - I do have a primarily-racing 3D engine working already (with a recent support of direct import from 3dsmax) so I will be very curious myself.


Golden days, eh I don't think my Wolfenstein ran at 15 fps other than perhaps main menu


Unfortunately, we now all experienced 60 fps+ on recent consoles and PCs, so it is now painfully obvious if something is running below 15 fps...




Sure looks awesome. But what kind of framerate was it at that level of detail on 030 ? I couldn't play F1GP on PC for years because formula in simulation mode is virtually unplayable in anything other than 60 fps. It's hard enough to play *properly* at 60 fps, let alone with random and frequent framedrops. It took many upgrades till framedrops in F1 became thing of the past and by that time, I believe we already had first 3dfx accelerators...


I think it was NFS1 that made me realize that even though I could play classic singleplayer just fine at 640x480 at <15 fps, to beat friend's record times, we had to lower the res to 320x200 and it took another month to notice what he said when he mentioned that it stutters even at 320x200 on my Pentium 100.


It did, I just didn't see it at the time, as it was much better framerate than 640x480.


But to achieve great times, you need precise control in curves, and 25 fps is nowhere near enough for that...


I just don't see how 030 could pull this off in 30 fps. Maybe it had options to turn texturing and details off ?

Virtua Racing was one of a bunch of untextured poly games SEGA released on the Model 1 platform, specs:
https://en.wikipedia.org/wiki/List_o...specifications
Main CPU is not particularly strong right there I think Vamp has the upper hand. Also the combined Matrix co processor and the FPU managed 80 MFLOPS which is probably less than you can get out of Vampire using FPU and heavy use of AMMX instructions.

I think properly utilized the Vamp can maybe beat the Model 1 hardware except maybe for the rasterizer. (But as you may have heard, they're working on that :-) rumour has it it something like the first voodoo, but since we know nothing about the time frame its probably just as good to forget it for now)
(Also, vamp has superior memory bandwidth)

Now, I'm not suggesting we do a straight Virtua Racing port and get sued by SEGA, but a game with those looks would be nice and quite doable I think. You could in the game design stage optimize stuff like poly count wherever needed to keep it consistent throughout the track. (Each model would have several LODs ant the lods could be swapped on the fly if framerate dropped below a certain number. (We had a solution like that in Unity3d for those PCs with only Intel integrated graphx a bunch of years ago).

Also, very interesting you can read objects from 3dsmax. What format do you read? .obj, .3ds, something else?
Btw, let me know if you need some low poly models to play around with and I can provide it for you.

[DamienD]

While on the subject of Virtua Racing; have you guys seen this: https://freds72.itch.io/virtua-racing

[PatmanQC]

Originally Posted by DamienD

While on the subject of Virtua Racing; have you guys seen this: https://freds72.itch.io/virtua-racing

Wow, that is fantastic

[vulture]

Yup! Great find D!

[VladR]

Originally Posted by skan

Just like Vampire fanbois.

I would argue it's ridiculous to label me as an Amiga fanboy, given the fact I never even saw Amiga in person, let alone touched it, as I grew up in Atarilandia.
But not sure if that would make a difference here...

Originally Posted by skan

On topic: we're talking about Outrun port on AMIGA, not VAMPIRE anyway!

Yeah, like that YT vid with Outrun that had 21k views, and that was on *cough* Vampire

[VladR]

Originally Posted by vulture

VirtuaGP ran like that even on a "lowly" 68020@28mhz and 4mb fast ram, it was a wonder to behold!

pics (vid) or it didn't happen

[VladR]

Originally Posted by eXeler0

Virtua Racing was one of a bunch of untextured poly games SEGA released on the Model 1 platform, specs:
https://en.wikipedia.org/wiki/List_o...specifications
Main CPU is not particularly strong right there I think Vamp has the upper hand. Also the combined Matrix co processor and the FPU managed 80 MFLOPS which is probably less than you can get out of Vampire using FPU and heavy use of AMMX instructions.

Thanks for the link - so it has 5 GPU coprocessors (16 MFlops each) with a theoretical 80 Flops throughput.
This is where the Vampire is at disadvantage, as it has only one processor. From my experience, there's a huge difference between:
1. having second execution path where you have to interleave your FPU instructions with integer ones
2. having parallel execution of FPU code on those 5 GPUs



On Jaguar, over the years, I refactored my engine to work completely in parallel over all chips and only doing the sync at end of frame.
While GPU is busy rasterizing last frame, 68000 was preparing render lists, handling input, AI, collision detection, audio, menus, HUD, GUI and everything else completely in parallel to GPU.


Meaning, the Sega Model 1, can do the same. It doesn't need main CPU super fast, its 16 MHz NEC is more than enough to the above, as all the per-vertex & per-pixel heavy lifting is done by the 5x GPU in parallel.


Of course, somebody has to program it that way, so therein lies the catch

Originally Posted by eXeler0

I think properly utilized the Vamp can maybe beat the Model 1 hardware except maybe for the rasterizer. (But as you may have heard, they're working on that :-) rumour has it it something like the first voodoo, but since we know nothing about the time frame its probably just as good to forget it for now)
(Also, vamp has superior memory bandwidth)

Yeah, the bandwidth is insanely high, and the texturing unit, once finished, may easily push V4 into Playstation territory (likely PS2 level). I should get the board soon, so may play with it in near future
I still don't think the singular nature of 080 can beat the Sega Model 1 with two separate processors (NEC + 68000 for Audio) and 5 additional GPU coprocessors.


Point being, Vampire may never beat it in flatshading, but once texturing unit gets enabled, well then V4 will jump to Warp 4

Originally Posted by eXeler0

Now, I'm not suggesting we do a straight Virtua Racing port and get sued by SEGA, but a game with those looks would be nice and quite doable I think.

Oh, yeah. That's for sure. We could go for lower vertical resolution, as that's where most performance is killed - processing scanlines. VR is 384 scanlines, so halving that to ~200 would help tremendously.
From my benchmarking, it's not really the number of polygons (it's only so much work with transformation and culling), but number of scanlines (each poly covers) that most affect framerate. Tall, thin polygons (e.g. vertical pillars) are the worst.

Originally Posted by eXeler0

You could in the game design stage optimize stuff like poly count wherever needed to keep it consistent throughout the track. (Each model would have several LODs ant the lods could be swapped on the fly if framerate dropped below a certain number. (We had a solution like that in Unity3d for those PCs with only Intel integrated graphx a bunch of years ago).

Level design can probably help the most - that's why the racing games that drove through mountains were always the best as there was no draw distance glitches - everything was naturally occluded by curves through the hills - thus no pop-up
I do have the LOD solution in my codebase even for Jaguar - each track segment mesh has high+med+low version and the engine just swaps the pointers at run-time. But, StunRunner track is obviously different to this, complexity-wise It's like, 50 polygons vs 500+


My next iteration of engine was meant to handle generic list of 3d objects - meaning it could process this environment (though the framerate would by abysmall on jaguar) - and I got basics working last year.


LODs - it would, however, be much much work to create the meshes here - all the terrains, roadside objects - it's quite a lot of work. I doubt we could reuse 3dsmax modifiers here much for low poly - probably need to recreate the meshes from scratch.

Originally Posted by eXeler0

Also, very interesting you can read objects from 3dsmax. What format do you read? .obj, .3ds, something else?

I, originally, used .ASE for my PC/X360 work, but for Jaguar eventually decided to write an .OBJ importer. Took about a week to iron out all details, but I think it's stable now...
Here's the screenshot showing my PC-based real-time previewer (crate object) without having to import the objects to jaguar to see how they look (I wrote a SW rasterizer on PC that is pixel-precise to jag). I will totally reuse this for Vampire:
Not sure if it is in attachments to the post or shows directly here within the post.
3D modeling productivity skyrocketed the moment I stopped running exporters, including the file, recompiling, deploying and running the executable on jag. Can't beat real-time

Originally Posted by eXeler0

Btw, let me know if you need some low poly models to play around with and I can provide it for you.

You're a 3d artist ? Why, that might come in handy

[skan]

Originally Posted by VladR

I would argue it's ridiculous to label me as an Amiga fanboy, given the fact I never even saw Amiga in person, let alone touched it, as I grew up in Atarilandia.
But not sure if that would make a difference here...

Yeah, like that YT vid with Outrun that had 21k views, and that was on *cough* Vampire

It's prerry obvious we have some misunderstanding going on here... anyway, ok, never mind.

[eXeler0]

@VladR theoretical question: How would you create the 3d track - from a driving *simulation* programming perspective.
I mean... the way I *think* its done is that the road geometry is only a representation of a "mathematical" model that is used for the simulation itself. Meaning you're not actually doing per polygon collision against the track/environment.

Most Amiga true 3d racing games have very simple road geometry, but if you look at say Virtua Racing on Model 1 hardware they use about 7 quads in width for the road geometry alone (yes, model 1 hw used quad polys, not triangles like modern hardware, that tech even got transfered into the Saturn).

So how would you do it, do a "mathematical model" of the track first then translate it into a polygon model, or the other way around, extract the necessary info from a polygonal model? Why do I ask this? Well for example if someone would create a medium poly track for testing, would it even be useful?

[VladR]

Usually, that's where the army of 3D artists comes in.

For example, in a first-person-shooter, when they create a level, they separately create collision-detection boxes. Or if the engine requires it, they create "walkable" polygons - which specify where exactly you can go.

The way I addressed it in my StunRunner is that in 3dsmax, I create a track curve/spline - along which the engine, at loading-time, extrudes the 3D mesh of the track.

The 3D engine then, each frame, only checks and interpolates the math on the center point between two consecutive track segments (each segment is just a single 3D point).

So, even if the 3D mesh of each track segment would be 1,000 polygons, it doesn't matter from performance standpoint of physics, as those polygons are totally ignored.


BTW, I am using quads both on Jaguar and Apollo too. It was a lot of work but it saves scanline processing costs by 50%, plus you save about 20% additionally on clipping.


How do you know it's about 7 quads for Virtua Racing ? Have you seen some screenshots ? Can you share some ?

[eXeler0]

Originally Posted by VladR

Usually, that's where the army of 3D artists comes in.

For example, in a first-person-shooter, when they create a level, they separately create collision-detection boxes. Or if the engine requires it, they create "walkable" polygons - which specify where exactly you can go.

The way I addressed it in my StunRunner is that in 3dsmax, I create a track curve/spline - along which the engine, at loading-time, extrudes the 3D mesh of the track.

The 3D engine then, each frame, only checks and interpolates the math on the center point between two consecutive track segments (each segment is just a single 3D point).

So, even if the 3D mesh of each track segment would be 1,000 polygons, it doesn't matter from performance standpoint of physics, as those polygons are totally ignored.


BTW, I am using quads both on Jaguar and Apollo too. It was a lot of work but it saves scanline processing costs by 50%, plus you save about 20% additionally on clipping.


How do you know it's about 7 quads for Virtua Racing ? Have you seen some screenshots ? Can you share some ?

Howdy Vlad,
I was just looking at a bunch of different situations in the game. I assembled some screenshot here:
http://www.exretro.com/galleries/seg...ing/index.html
Take a look at the pix at the bottom of the album. Its when the road isn't flat where you can see the geometry. They aren't using any textures so they kind of randomized colors on the flat shaded quads, so its fairly easy to see the geometry. So maybe its like 8quads for the road + more for the "edges of the road".
Id say the key difference here compared to most old racing games is that the road isn't flat on the X-axis so to speak. Its not just flat with an angle, it actually has a curvature like the inside of a bowl rather than just an angled line.
Now.. lets toy with the idea one would wanna remake OutRun in polygons, then that wouldn't be an issue because road is always flat in X axis. (Just changes in Z-value.)

[VladR]

Originally Posted by eXeler0

Howdy Vlad,
I was just looking at a bunch of different situations in the game. I assembled some screenshot here:
http://www.exretro.com/galleries/seg...ing/index.html
Take a look at the pix at the bottom of the album. Its when the road isn't flat where you can see the geometry. They aren't using any textures so they kind of randomized colors on the flat shaded quads, so its fairly easy to see the geometry. So maybe its like 8quads for the road + more for the "edges of the road".

Thanks for the screenshots ! I just saved them and am browsing them right now. Vracing_s9g.png does, indeed, show it nicely - the road geometry isn't flat. Never noticed that before at those racing speeds

Originally Posted by eXeler0

Id say the key difference here compared to most old racing games is that the road isn't flat on the X-axis so to speak. Its not just flat with an angle, it actually has a curvature like the inside of a bowl rather than just an angled line.

From programming standpoint, when such behavior is required, you must have a full-blown camera matrix solution executed per every vertex, because your camera is now composed from LookFrom point and has a LookAt point. Plus there is a Roll around that Look Vector which depends on the road's curvature.
So, it is much more expensive to compute per each vertex than, say, OutRun or StunRunner (though I suspect StunRunner does full matrix solution).



Now, on V4, at 85 MHz, all code written in properly interleaved ASM, that might not be an insurmountable issue.


But even V4's FloatingPoint Unit takes 6 cycles for addition and 9 for division, so it'll add up real quick.

Originally Posted by eXeler0

Now.. lets toy with the idea one would wanna remake OutRun in polygons, then that wouldn't be an issue because road is always flat in X axis. (Just changes in Z-value.)

If I was going for this, I already have the XYZ displacement curve, so you already get the Y-axis - e.g. hills and valleys.
At run-time, I must interpolate the camera elevation (otherwise the hills would disappear above top screen edge and valleys below bottom screen edge), so every frame I compute the displacement offset for Camera.YPOS.
A bouncing effect for the camera (e.g. when you land on a flat road and how high you bounce depending on the speed) is about a week of work.


It would be very easy to add vehicle speed-up/slow-down depending on how steep the hill/valley is (as that's computed each frame anyway) - kinda like in NFS (perhaps OutRun already has that ?)

[VladR]

Originally Posted by eXeler0

Well for example if someone would create a medium poly track for testing, would it even be useful?

Are you volunteering for this ?


Any test 3D mesh would be very useful as that would give us the basic performance characteristics of the environment - number of scanlines in the scene.


My 3dsmax loader already displays that info, so you would see it, right there, on PC.


And it wouldn't hurt to see the visuals


I don't yet have my V4, but about a week ago my order got processed, so it shouldn't take more than 2-3 weeks till it ships.


Currently, I am in the middle of porting my code from Jag and working under WinUAE. As of right now, I have basic 3D transform, clip and scanline fill. Though, because of the RTG 24-bit, I decided to go for a Radiosity lighting rendering test (as that's the best use case for 24-bit colorspace), which would be more useful for the first-person shooter, than racing game. But, base routines are same anyway - loop through vertices, transform, clip, scanline loop.


I am currently heavily leaning towards full 24-bit colorspace (16.7 Mil colors), as it's quite fast to fill via Apollo's fusing. A 128-bit write should take just 2 cycles, which is 0.5cycle for a 24-bit pixel. And 640*480*0.5 = 153,000.
At 60 fps, you get 85 MHz / 60 = ~1.4 M cycles per frame. For a single CPU pipe (you have two, but let's go for worst case).
So, the fillrate cost of a screen fill should take only about 10%-20% of the frame budget.


The next greatest performance eater is scanline loop.


On Jaguar, a heavily optimized ASM RISC code on GPU could process about 2,100 scanlines at 60 fps. From my current early experiments with 68040 code it appears, a factor of order of magnitude is easily doable on V4.


But, for 20,000 scanlines, you need a lot of polys, so the transform/cull stage will rise up in cycle cost drastically too.


Before I make a first benchmark on real V4, it's impossible to precisely guess.




But we gotta start somewhere and VirtuaRacing environment's complexity would make for a nice target to shoot for

[amiwolf]

Originally Posted by VladR

... But even V4's FloatingPoint Unit takes 6 cycles for addition and 9 for division, so it'll add up real quick. ...

For real? That isn't what their FPU wiki states:

https://wiki.apollo-accelerators.com...pollo_core:fpu

I guess the documentation might need an update.

[eXeler0]

Originally Posted by VladR

Are you volunteering for this ?


Any test 3D mesh would be very useful as that would give us the basic performance characteristics of the environment - number of scanlines in the scene.


My 3dsmax loader already displays that info, so you would see it, right there, on PC.


And it wouldn't hurt to see the visuals


I don't yet have my V4, but about a week ago my order got processed, so it shouldn't take more than 2-3 weeks till it ships.


Currently, I am in the middle of porting my code from Jag and working under WinUAE. As of right now, I have basic 3D transform, clip and scanline fill. Though, because of the RTG 24-bit, I decided to go for a Radiosity lighting rendering test (as that's the best use case for 24-bit colorspace), which would be more useful for the first-person shooter, than racing game. But, base routines are same anyway - loop through vertices, transform, clip, scanline loop.


I am currently heavily leaning towards full 24-bit colorspace (16.7 Mil colors), as it's quite fast to fill via Apollo's fusing. A 128-bit write should take just 2 cycles, which is 0.5cycle for a 24-bit pixel. And 640*480*0.5 = 153,000.
At 60 fps, you get 85 MHz / 60 = ~1.4 M cycles per frame. For a single CPU pipe (you have two, but let's go for worst case).
So, the fillrate cost of a screen fill should take only about 10%-20% of the frame budget.


The next greatest performance eater is scanline loop.


On Jaguar, a heavily optimized ASM RISC code on GPU could process about 2,100 scanlines at 60 fps. From my current early experiments with 68040 code it appears, a factor of order of magnitude is easily doable on V4.


But, for 20,000 scanlines, you need a lot of polys, so the transform/cull stage will rise up in cycle cost drastically too.


Before I make a first benchmark on real V4, it's impossible to precisely guess.




But we gotta start somewhere and VirtuaRacing environment's complexity would make for a nice target to shoot for

Yes, I can provide you with some models. If you have a little patience then I was thinking about remaking Stage 1 from OutRun with polygonal assets ;-)
I actually started "mapping out" the track from watching video of the Arcade game. I also have a list of the assets. I could do all these even with LODs, but what I can't do is give you a deadline for when I can find time for this. (you know, lots of work, 2 kids, priorities.. ;-) Should probably start with a simple track geometry and the increase complexity as the code can handle more special cases etc..

Now, Outrun is pretty flat compared to something like VirtuaRacing so still dont know if it would look awkward without something like a fog hiding near clip plane. Need to do some testing for this.. (Also, Stage 1 doesn't really have much of a backdrop.)

[VladR]

Originally Posted by eXeler0

Yes, I can provide you with some models. If you have a little patience then I was thinking about remaking Stage 1 from OutRun with polygonal assets ;-)

When I say OutRun in this context - I mean the arcade gameplay and physics of OutRun.


I don't really think it's possible to "remap" the purely 2D sprite asthetics of classic OutRun into flatshaded polygons. The two are basically mutually exclusive, visually. So our "OutRun" would look nothing like the original, obviously.


But, it could handle similarly. Or, have an arcade feel to it.




Also, the tracks in OutRun were created based on what kind of road the engine could do, and since it's a scanline road, there is a limit to what kind of curves&hills it supports.


We wouldn't really have that kind of limit in 3D, as the road mesh is constructed of linked segments and physics takes into account XYZ displacement from two neighbouring segments, so we could have any combination of short/long flat/steep hills/valleys.


It couldn't be as crazy a track, as say - Stunt Car Racer, as that would need a completely different physics and track code.




Remember the first Alpine Segment in NFS1 ? This was the first time the racing game had a really long jumps into an actual deep valley. Can't do that with a 2D scanline road. But in 3D, it doesn't matter to a 3D engine - it becomes an artistic / level design expression at that point.

Originally Posted by eXeler0

I actually started "mapping out" the track from watching video of the Arcade game. I also have a list of the assets. I could do all these even with LODs, but what I can't do is give you a deadline for when I can find time for this. (you know, lots of work, 2 kids, priorities.. ;-) Should probably start with a simple track geometry and the increase complexity as the code can handle more special cases etc..

Of course, no worries. This is more of an exploratory exercise at this point.
Just make sure the polygons are quads and there are no polygons you cannot see (e.g. delete backface polys). There are some restrictions in 3dsmax how the quads must be edited and which modifiers - I don't recall exactly ATM, but generally it must be Editable Poly and you use Quadrify otherwise 3dsmax doesn't put 4 vertices into the OBJ file (and still breaks it down to triangles, even though in your scene it shows as a quad).

Originally Posted by eXeler0

Now, Outrun is pretty flat compared to something like VirtuaRacing so still dont know if it would look awkward without something like a fog hiding near clip plane. Need to do some testing for this.. (Also, Stage 1 doesn't really have much of a backdrop.)

Generally, the way to avoid the fog is to create track that has a snake form - from one curve to another, making sure that the curve stays within the limits of engine's draw distance.


We don't have that info yet at this point. But, for sure, applying a per-polygon fog color shouldn't have a measurable performance impact, so fog is not something to worry about.
Now, if we were to have a per-scanline fog color, that's a different thing altogether and that would have significant impact on performance, since we're talking few 10,000s scanlines, so you multiply the cost of that computation by, say, 20,000x...