Model 3 Step 1/1.5 and Step 2 Video Board Differences

[MetalliC]

What doesn't make sense to me is Hikaru's graphics chips running at only 41.6 MHz when the "less powerful" NAOMI/Dreamcast runs its PowerVR2 chip at 100MHz, nor Model 3's graphics chips running at only 33 MHz when the Model 2 runs at 50 MHz.

the main problem of HOLLY chipset is lack of hardware T&L, and this also was quite hard task for the CPUs of the time, for example 200MHz SH-4 was able to calculate only up to 30000 or a bit more vertices with "good enough" lighting per scene @60Hz, which doesn't looks impressive, right?
and it also was huge PITA for game developers, because besides of T&L main CPU has a lot of other tasks to do.

so, Hikaru was actual (only) during 1999-2000, when Sega had no other modern "premium class" arcade platform with hardware T&L.
but, it seems that this platform was not good enough and powerful enough to meet the overheated expectations of the "Sega Model 4" name, so it was never officially called like that, and was quickly retired.

then was released Naomi 2 which solved T&L problem and Hikaru was immediately abandoned.
and IMO not only because Hikaru was "more expensive" (price of arcade PCBs never was a problem for Sega), but because it turned out weaker than Naomi 2, and more hard to work with, lacked modern software tools and libraries, etc.


PS: as of PVR2 CLX and 100MHz - it is worth to remember it had unified memory, which actively used by: TA(Tile accelerator) when write display list data sent by main CPU, ISP(rasterizer) which fetch display list to do HSR and polygon sorting, TSP(texture processor) which fetch polygon parameters and texture data and write rendered frame, CRTC - read bitmap to display onscreen.
so, these 100MHz of VRAM bandwidth divided between all these subsystems, while in Model 3 or Hikaru for example texture RAM exclusively accessed only by texture "processor".

[Ian]

Yes, Model 3 has one color per polygon; is the same true for Hikaru?

the question was about does Model 3 have per-vertex colors? (like almost all the other GPUs). but it looks it doesn't, same as Hikaru.
as of one color per polygon - yes and no, Hikaru implements typical late 90s fixed function T&L with "material", "lights", "texture heads" etc type objects, while Real3D 1000 / Model 3 is more archaic early-mid 90s device and have almost everything in polygon header. Hikaru's materials have several colors, but they are mostly not understood, currently we use only one as diffuse and ignore others. see next msg.

If it's true that Hikaru uses two 2048x1024 texture sheets just like Model 3 does, then I might just be convinced that Real3D came up with it because pretty much everything else uploads textures as contiguous blocks of data.

yes, Hikaru uses 2048x1024 "texture sheets" banks, 2 of them.
in general it is not something totally unique, iirc PlayStation 1 GPU uses same concept.

The graphics chip part numbers suggest that most of them may have been designed shortly after Model 3 Step 2.x; the graphics chips on step 2.x have the part numbers 315-6057 to 315-6061 while most of the graphics chips on Hikaru have part numbers 315-6083 to 315-6087; the exceptions are the two Atlantis chips (315-6197) which still predate the PowerVR chip (315-6267) used on Dreamcast/NAOMI.

It looks to me like Hikaru was conceived around 1997 or so to be the successor to Model 3, but then the much cheaper NAOMI came along so Sega decided to only use Hikaru for games which really needed the extra power.

sadly it's almost nothing known about Hikaru development. all is what known for sure - this platform was released 1999/7/12 (July 1999) as said in Brave Firefighters game ROM header. everything else is speculation.

as of Dreamcast/NAOMI: in short, it was most active developed during 1998, design of HOLLY chipset was finalized late summer 1998, from early autumn 1998 Videologic/ImgTec started work on ELAN T&L for Naomi 2.
in about same time, end summer - early autumn, Hitachi has been finishing work on SH4 CPU, Katana Set 4 proto/devbox documentation from August 1998 have list of SH4 CPU bugs in this device. they was fixed until November 1998 Japanese Dreamcast release.

obviously, they was unable to create Hikaru any earlier, until all the work on SH4 CPU was done and all it's bugs was fixed.
but, as you noticed, almost all the GPU ASICs have quite small part numbers, so yes, it's possible they was created during 1997-98 as standalone PCI GPU or for some other project, but later Sega decided to build SH4-based hardware with it.

Sega Hikaru is a pretty crazy thing. I assumed they would have just gone with some sort of, off the shelf GPU, I mean that's what the model 3 is. But it seems no they probably created this GPU specifically for this fire fighters game lol. Feature wise it's not really that complex, limited texture types supported, probably very limited actual rendering modes supported, but it has great support for lighting. I was a little skeptical that it was actually doing per pixel lighting, I mean you can sort of fake it just by tessellating geometry more but no it actually seems to be doing per pixel lighting. None of the rendering APIs back then dx6 or opengl supported per pixel lighting. I don't think real3d were involved in this gpu at all, I mean there are a few similarities but nothing really stands out.

I think the real challenge back then was not making a GPU so much, but making something cost effective. SGI had been making all sorts of GPUs but the hardware was insanely expensive. Why 3dfx succeeded was because they brought high end features down to consumer level at a price that wasn't crazy. And at the time they did it by making all sorts of shortcuts and compromises which were fine at the time, only 16 bit colour, extensive use of pre-calculated look up tables, probably most of the maths was done with limited / fixed point precision instead of full float. It was said that the Hikaru hardware was very expensive to make, so this is probably the reason it's shelf life was so short. The actual real3d pro-1000 standalone was also very expensive, in the region of 20-30 grand which was a huge amount back then. With the rapid decrease in the process node sizes, and the decrease in chip costs together with all the other manufacturers making 3d hardware, it was probably the nail in the coffin for bespoke 3d hardware.

[MetalliC]

Feature wise it's not really that complex, limited texture types supported, probably very limited actual rendering modes supported, but it has great support for lighting. I was a little skeptical that it was actually doing per pixel lighting, I mean you can sort of fake it just by tessellating geometry more but no it actually seems to be doing per pixel lighting. None of the rendering APIs back then dx6 or opengl supported per pixel lighting.

I'm personally don't believe at all Hikaru had per pixel lighting, besides of that more-less trusted sources like system16 https://www.system16.com/hardware.php?id=724
claims Hikaru had Phong lighting, but doesn't claims it was per pixel.
in general it doesn't sounds any realistic because a) it require many-many-many times more computing power as for ~1997 made 41MHz device, b) the very most of gamers of the time simply will not notice any difference if lighting was per-vertex or per-pixel. so, it's simply doesn't have any sense.

I tend to thinks it's some Sega fanboys spreaded wrong rumors, while this thing actually had per-vertex (Blinn-?)Phong lighting model, similar to OpenGL 1.x fixed function lighting which used Blinn-Phong.
and in general, command and feature set looks very inspired by OpenGL 1.

for comparison, Naomi 2's ELAN T&L coprocessor @100MHz was able to do per-vertex lighting up to 6 light sources with no performance loss (up to 16 in total)

I don't think real3d were involved in this gpu at all, I mean there are a few similarities but nothing really stands out.

is there any better options? is there any other GPU of the time which looks more similar to Hikaru's GPU, or at least doesn't looks way too different?

after quite a lot of researches, I'm personally see no other options.

[Ian]

I'm personally don't believe at all Hikaru had per pixel lighting, besides of that more-less trusted sources like system16

I'm certain it has per pixel lighting.



Look at the specular highlight, that is simply not possible unless the geometry is highly tessellated, which it isn't because you can see an identical model on the right side which I've traced out in red.

https://youtu.be/wyZV8Xbnu4U?&t=179

in general it doesn't sounds any realistic because a) it require many-many-many times more computing power as for ~1997 made 41MHz device, b) the very most of gamers of the time simply will not notice any difference if lighting was per-vertex or per-pixel. so, it's simply doesn't have any sense.

Hmm yeah, but it is fixed function lighting, so most likely baked into h/w rather than running some kind of shader. Don't forget the model 3 also had per pixel lighting, the real3d headlight which is used in various games like lemans24 at nighttime. It was used in virtua fighter 3 team battle, but missing on the dreamcast version because I don't think the dreamcast h/w could replicate that effect. But yes I don't think it would have been a massive visual downgrade it the lighting was only per vertex. But don't forget this is high end hardware, not something consumers would have at home.

[gm_matthew]

I'm personally don't believe at all Hikaru had per pixel lighting, besides of that more-less trusted sources like system16 https://www.system16.com/hardware.php?id=724
claims Hikaru had Phong lighting, but doesn't claims it was per pixel.
in general it doesn't sounds any realistic because a) it require many-many-many times more computing power as for ~1997 made 41MHz device, b) the very most of gamers of the time simply will not notice any difference if lighting was per-vertex or per-pixel. so, it's simply doesn't have any sense.

I tend to thinks it's some Sega fanboys spreaded wrong rumors, while this thing actually had per-vertex (Blinn-?)Phong lighting model, similar to OpenGL 1.x fixed function lighting which used Blinn-Phong.
and in general, command and feature set looks very inspired by OpenGL 1.

for comparison, Naomi 2's ELAN T&L coprocessor @100MHz was able to do per-vertex lighting up to 6 light sources with no performance loss (up to 16 in total)

There's a distinction between the Phong reflection model (ambient, diffuse and specular lighting) and Phong shading (per-pixel normal interpolation). System 16 claims that Hikaru performs Phong shading, so either it's claiming per-pixel lighting or it got the two terms mixed up.

I agree that Hikaru is almost certainly not performing the full Phong shading calculations for each pixel, given how expensive they are. That being said, in this video of Planet Harriers running on real hardware, the specular highlights on the flying vehicle at 0:41 and the joystick during the "how to play" sequence starting from 2:19 definitely look like there's more than just simple Gouraud shading going on.

I'm only guessing, but I reckon that Hikaru is probably doing some kind of trick to produce results similar to Phong shading, e.g. perhaps it's performing angular interpolation with lookup tables built into the hardware.

On a somewhat related note, Model 3's geometry processor takes several shortcuts to boost performance:

1. Vertex/face normals are not normalized after transformation. This means scaling a model up leads to the lighting values also being scaled up; later Model 3 revisions add a "model scale" parameter to correct this.
2. Specular lighting for Gouraud-shaded polygons just uses the same N dot L value as diffuse, only with an exponent and multiplier.
3. Specular lighting for flat-shaded polygons uses R dot V like the Phong reflection model, but it uses V = (0.0, 0.0, 1.0) as a fast approximation and doesn't apply any exponent at all.

[MetalliC]

I'm certain it has per pixel lighting.
Look at the specular highlight, that is simply not possible unless the geometry is highly tessellated, which it isn't because you can see an identical model on the right side which I've traced out in red.

geometry looks like that, about 55K vertices per scene in total
I'm a bit curious how it will look with per-vertex lighting, will do it in emulator a bit later.

[MetalliC]

I agree that Hikaru is almost certainly not performing the full Phong shading calculations for each pixel, given how expensive they are. That being said, in this video of Planet Harriers running on real hardware, the specular highlights on the flying vehicle at 0:41 and the joystick during the "how to play" sequence starting from 2:19 definitely look like there's more than just simple Gouraud shading going on.

I'm only guessing, but I reckon that Hikaru is probably doing some kind of trick to produce results similar to Phong shading, e.g. perhaps it's performing angular interpolation with lookup tables built into the hardware.

Yes, I think so too. probably they do all the expensive math like R*V etc per-vertex but also do some math tricks at per-fragment level to make it look more Phong-ish.

On a somewhat related note, Model 3's geometry processor takes several shortcuts to boost performance:

1. Vertex/face normals are not normalized after transformation. This means scaling a model up leads to the lighting values also being scaled up; later Model 3 revisions add a "model scale" parameter to correct this.

very interesting!
I was wondering - why Hikaru GPU models always have "fixed point vertices coords scale exponent" commands, even if model uses float32 type vertex commands? - it seems they use same optimization to not perform proper normal normalization.

+1 very Real3D-specific feature which probably doesn't exists in any other GPUs

[Ian]

Vertex/face normals are not normalized after transformation. This means scaling a model up leads to the lighting values also being scaled up; later Model 3 revisions add a "model scale" parameter to correct this.

That isn't an optimisation really, that's standard behaviour in most 3d apis. In legacy opengl if you want normalisation you have to call glEnable(GL_NORMALIZE) otherwise if you scale the model it gets brighter. Normalisation was never the default because the square root was a fairly expensive operation.

Also looking at the wireframe i'm certain it's doing per pixel lighting.

[MetalliC]

there is different ways to solve or optimize this "problem". for example Naomi2's ELAN use 2 matrices, one 4x4 for vertex transformation and one more 3x3 for normals.

as of lighting - sorry, in prev-prev message I've used wrong wording, I don't believe hikaru had per-fragment Phong in modern sense, with all the math done per each fragment.

as was suggested above, it's possible they use some interpolated lighting value as lookup table index, and fetch from it values with non-linear distribution, to make specular etc look nicer.
or some other kind of "close enough" approximation.

for sure they use similar approach for spot-type lights, where they use cone angle coefficients with "penumbra table" (cosine-based), high likely at per-fragment level.
it's the only user defined table in Hikaru's lighting system, and only used for spot-type light sources (the ones which have position, direction and cone), not for simpler position-only or direction-only light sources.