Thought about 3d

Started by iWasAdam, September 15, 2021, 07:04:23

Previous topic - Next topic

iWasAdam

OK. We all know I've got a workflow and 2d render system for 3d. But one thing always keeps cropping up:
position of 3d objects, cameras, lights etc.

My thought here is take the concept of a 3d editor and deal with just the top down view. and at any stage in a game you could call up the view and it would show you the actual placement of 3d models, cameras etc.

How you use this view I am not sure as yet, but it would certainly be helpful to see layout and positions of things - maybe with other data being showed too - like camera frustrum?

I'm sort of brainstorming here....

Derron

As your whole engine is already 3D ... why limit to "top down" - you should be able to render it at any camera angle you want (plus the information billboards as "always facing towards camera" 2d things)



bye
Ron

iWasAdam

you've slightly missed the point. we already have the 3d view from the camers. this is the overview showing everything including the camera lights, etc
Here' is the first working version:

iWasAdam

jeez that was quick and painless...  :o
OK addendum to Derons post. Here are 2 shots of Neon Overdrive with the 3d overview.
Each shown grid position is 1. with the camera being the cyan line, position and eye
first the main menu


And now for the more interesting shot from in game:
Here you can see the track in front of you, plus some trees and the ship off to the right.
The 2 thick white bands - thinner and longer at bottom and thicker shorter (just above center) are the draw horizon items. so instantly you can see how the game is being drawn - but dont forget that this isn't static it is updating with each frame too...

iWasAdam

#4
for the really curious - although you wont see it in the game - The ship only moves left / right. it's everything else that moves.

the map is checked and an item is placed in a 3d list far away (around position z300)
each frame the 3d list is checked and everything in the list is decremented by the current speed value. so the above item at z300 become z298
then you render everything to the camera and voila - moving roadway

and for collision - when a 3d object is drawn - just check if it is near the ship - simple
There's more to it than that but that's the simple explanation. I wonder how I did the curved roads?

And for the really really curious....
I've got something in the back of my mind to do with what you send to the gpu RE proper 3d... stay tuned

blinkok

For me i always refer to a 3D proggy when trying to do a 3D utility. This is a very old 3d proggy. The camera is the red/yellow thing and the light is the spiky red thing.
Most 3D proggys have multiple views; top, right, front, bottom, left etc but you can also add a camera ad make that the view

iWasAdam

I've already got an advanced low poly 3d modeler with Rameses:


With the above this is ingame. with further thoughts about writing a new 3d renderer.

I know that this is starting to stray into Unreal concepts in some ways. but it is all about learning, thinking and coming up with a new way of doing something.

As an example.
In a previous game I was getting a solid 35fps with a custom 3d renderer. moving to something more advanced and up to date the fps halved to 17fps <- In my opinion that shows that something was being done very wrong with the new renderer (not mine btw).

But it goes deeper. In my books, you should be given a solution that allows you to create materials, new things, different things. The current 3d render I inherited is so fixed, so complex and so badly written that it needs to be rewritten.

The one important thing I have picked up is with render systems like Unreal there is a lot of processing going on with the CPU and the models before they even get to the GPU. I think that their new solutions with megascans, lumen, lighting etc are all doing some amazing stuff before they go into 3d.

My aim is the take some of this and rebuild a new 3d system. the 2d vector 3d system works very well and is fast. I feels that this could be used as the base for something a bit special...

mainsworthy

you should be a proffessor Adam, you do some cool stuff,


iWasAdam

I only have one issue with VR and oculus: facebook  :o

VR is something to deal with once you have got a system fully operational. There is a lot of work and thought to be done before I would think about this.

But.... And this is much more important - I can never see or be able to ever debug VR... I am completely blind in one eye! I have never seen or have any depth systems or stereo vision ;(

mainsworthy

Sorry about that, BUT you can sure program Adam.

iWasAdam

Not a problem here - lol - it does seem that i can visualize 3d is a different way from normal people...

Now here's something very interesting - it's gonna be a bit technical but bear with me.
First an image with a strange bug - making all the blue lines


I know what the problem is:
stuff behind the camera is being drawn

If we look at the new topdown view you can see the camera (cyan triangle) plus the strange junk (i've highlighted this in red so you can better see it)

Now I could see the problem I could try and track it down...
The code deals with each 3d point transforming it from world space to camera space. it 'should' mark points that are not in the cameras view and then reject these points later.

Checking the code and doing debug sort of returned the results I was looking for - the points were being marked as visible, checked and set a not visible correctly. but there was something odd going on with points being reset... hmmmm

OK the code uses an internal flat model where there are some globals that are being reused throughout. One of these was tied to the visibility.
looking further a single point would go though transformation more than once <- RED FLAG for global flat systems

a point was being set as visible then marked as not visible. then reused and set back to being visible - result being junk krept back into the system and not being culled correctly ending up with junk on screen.

A quick snip here and a quick change there, and the visibility flag is now being set when you first manipulate an object into place. it gets flagged and cancelled and stays cancelled. result it works :)

For those who really want to know. is called frustrum culling. where the camera has a min and max view plane

Here's the corrected result:






mainsworthy

I would of thought if a point is not visible, then the points its connected to still have to draw to it, so just making the point not visible would not work, because the lines are multipointed. not sure how you do any of this, but looks the best project i have seen an ordinary guy do.

iWasAdam

yes and no...
hmmm
a point is visible if it is in the camera frustrum - it could be left or right of the screen and still be classed as visible - there are also camera bounds. But in essence let's just say if the point CAN be seen then it's visible.

A Line has 2 points, so.... we do the following in order
-  if both points are visible the draw it
- if both points are above or both are below the frustrum then is not drawn
- 1 or both points are sort of unknown, so some extra checks must be made to see if the line is visible

triangles are made from lines - so see above

to do hidden face removal you need normals (vector pointing from the triangle surface)
Luckily Normals are part of my internal system and are saved with the model.
a rotated model just rotates the normals with the same calculations, so is quite fast.

to remove lines that form a flat face you do the following:
- load the model
- for each triangle, compare it against other triangles with SIMILAR normals - not the same, but with a slight margin of error
- now for each triangle compare each line against the other triangles lines - a line AB1 must be compared to both AB2 and BA2 and then both marked as hidden if they are the same
- when you draw a triangle - you now only draw those lines that are marked visible

to do face removal you do the following:
- check the triangle normal against the camera normal.
- if it is minus then the triangle is facing away and is not drawn
- if it is positive then the triangle is visible - add this to the list of triangles that can be drawn

NOTE
this is for wireframe
for filled triangles - you will need to add some form of depth sorting. but.... depth is best handled by the gpu as it can do that instantly...


Rotations...
Most objects don't really rotate, or only rotate around the upright (Y) axis. so you dont really need quaternons, but can do very simple sin/cos on the vertex list.
in essence (for each 3d object) you will need x,y,z, rotx, roty, scale
but maybe you can have a different set of commands such as:
DrawModelXYZ
DrawModelXYZScale
DrawModelXYZRot
etc

The reason for having lots of different version of virtually the same thing, is that with each version you only have the needed code - thus meaning there is no redundant code taking up cpu time for no reason.

You can then extend these with different color render techniques:
- normal, which would be draw with the model colors
- mono, draw with a single color
- col, draw with a color affecting the model colors. E.G. if the 3d model was in shades of grey, and you draw it with red, you would get shades of red, or blue, etc.

An example would be armour - the armour model is shades of grey
- draw with brass as your base color, and you have brass armour
- draw with white and you would have silver armour
- draw with yellow/gold and you would get gold armour

But you have to think of all of this either before you start coding, or learn as you go and write something better with all your new found knowledge later...


Kryzon

@iWasAdam there are several FPS games that use this kind of thing, a navigation map overlay that helps you not get lost.
 
Turok series: 
 
 

3D Realms games (Duke Nukem 3D, Shadow Warrior and maybe more):