Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / (Normals * Vector * Lighting * Vertex) - Help = Bad Shading on My Terrain :(

Author
Message
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 18th Dec 2007 19:51
Hi Posters - As the title suggests - I have a problem with how my terrain poly's reflect light.

I basically make a mesh - into an object - I Lock Vertices - and change the "Y" coord's to different heights - based on a height map or USGS satelite info - whatever. I Get something that looks like this after some smoothing and texture:


FULL SIZE: http://www.jasonpetersage.com/img/TankGame41_HomemadeTerrainEngine.png


Looks ok - BUT - the shadows are all...I mean mostly...wrong. This is my problem.

I heard the SET OBJECT NORMALS function (Normalizes Vertex Normals) is broken on big stuff - (I heard Green Gandalf discovered that bug - on mesh bigger than 100x100 or something) so I'd rather not use that. (I have more than 100x100 in that mesh you see in the pic.)

Pharosear (Frank) Helped me with some maths in the DarkGDK Forum - but the results were dismal - probably my fault - because I understand everything in it after working with it ....except the cross product thing... I just took his word for it. .

Anyway - I THINK I need to learn how to set all my VERTEX NORMALS so they are (at minimum) "Perpendicular" to the Poly Face. (Flat Shading Technique) And if I can get this - I THINK I can handle "averaging" the VERTEX NORMALS (that are "welded" kinda...same position - different poly(s)) to get that "Gouraud
" shading... I THINK that's how its done. Gouraud is supposed to soften "edges" by AVERAGING Normals of adjacent polys' vertexs.

Any suggestions? Thanx in advance

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 18th Dec 2007 20:25 Edited at: 18th Dec 2007 20:33
Hi,

Here is how you generate a normal for a triangle, given that the triangle consists of vertices v0, v1, and v2 wound in clock-wise order.

v01 = v1 - v0
v02 = v2 - v0

normalize( v01 )
normalize( v02 )

normal = cross( v01, v02 )


Now in DarkBasic code, that's something like this:


Let me know how that works. I might have the order of crossing mixed up. It's been a while.


Edit:

Cross product will generate a vector that is perpendicular to two other vectors. This is why you are calculating the X vector and Z vector of the triangle, then crossing them to get the Y vector, which will point up out of (perpendicular to) your triangle.

To do smooth lighting once you have the normals working, all you have to do is add all the adjacent normals together then divide the resulting vector by the number of normals you added together. Very simple.

Edit Again:

I read your other post in the DarkGDK forums. Here is what I posted there:

Do not use SQRT, it is extremely slow. Don't do the work to normalize your vectors either, DarkGDK has a built in function that uses DirectX helper function to do it for you - dbNormalizeVector3( resultID, sourceID );

Also, vertex normals don't exist really. To get them you take the average of every triangle's normal that the vertex is a part of. In other words, one vertex of a triangle might be shared among 4 triangles. That vertex normal would be the sum of all 4 triangle normals added up, then divided by four.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 03:06 Edited at: 19th Dec 2007 03:41
Ok - I followed your instructions - Am so glad you guys are lending a hand. these are my results so far:

Sphere = Light Position

No Normalization

Full Size: http://www.jasonpetersage.com/img/Normalization_NONE.PNG


Manual Method - Pharoseer - this is your way - I know I musta goofed it though

Full Size: http://www.jasonpetersage.com/img/Normalization_Manual.PNG





DarkGDK 3DMaths - TParkin - this is your way - I probably goofed this too

Full Size: http://www.jasonpetersage.com/img/NormalizationVia3DMaths.PNG




Dark Basic "MATRIX" Classic Tutorial - translated to DarkGDK and retro fitted to my "poly mesh"



Full Size: http://www.jasonpetersage.com/img/Normalization_DBCTutorial4Matrix.PNG




Now... I am so looking for suggestions. Meanwhile - I'm going to try to take all I've learned from you guys - and what someone told me about atanfull and see what I can do while I wait for some New Eyes ... That is - any eyes but my own

Thanx To All!

[edit]Was looking this over - and although I want general Vertex Help - the code is darkGDK'ish even though I'm working on a principal that is germain to all of Dark+anything... so --- I'm going to copy this msg to GDK side - I use both languages - and I don't want to start getting mod's mad[/edit]

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 19th Dec 2007 10:09 Edited at: 19th Dec 2007 10:17
Not sure if you've considered this, but why not forget normals altogether?

You could make your own vertice light mapping system quite easily, it's more accurate because it can be based on the geometry, rather than just the polygon angle - like a tall mountain could cast a shadow. But one major plus is that you can disable lighting on your terrain which makes it display about 20% faster. Having that level of control over terrain lighting can be very useful, more realistic lighting and shadows, you could have as many fake lights as you want, you can stylize things to look exactly how you want (mimicking standard lighting is very easy). You could even use vertice lighting for water colouring as well, like making anything under water have a blue hue to it depending on depth.

Also, as this is a tank game (I think), you could use the vertice colouring to scorch the terrain, like calculate a 2D terrain lighting array, but then when there's an explosion you can set the colour of the corresponding terrain vertices to black and it'll scorch it nicely.


less is more, but if less is more how you keeping score?
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 15:59
I Like It - (I can envision "Scorching" as well as perhaps making holes - or depressions - With a little animation - Could probably make Dirt "react" one way and Rock - differently - even throwing projectiles that hurt regular infantry... a 5 pound rock getting hurled at you - HURTS - Can kill... Would be CRAZY COOL....

But I don't understand how I could do as you say yet. I only understand that the "Flag Pole" Sticking up from the Vertice (This normal) is basically the "Angle Finder" Where the Light has a "Direction it comes From" When They Cross - depending on how GREAT or SMALL the Angle - the Light Brightness changes - (more or less)

How would I do this Trick you mention? Make the OBJECT not pay attention at all to the light - then the Vertex normals somehow become "How Bright" Values somehow (That ignore light sources? e.g. Fake Lights?)

Thanx in advance - this is interesting - and the more I know know the easier to plan correctly

BTW - Yes - this is a tank game - but my scope is kind of set High - I Dare Say - FPS + Flight Sim'ish + (Flight Sim physics are beyond me - but I think I can make a FUN "Gamers" go of it ) and eventual MultiPlayer - So people can log in - jum pin a tank - a heli - a chopper - a jet - jump out and parachute - Hide in Tree Canaopies - Grass - BUT - One thing at a time. One might Argue I'm doing something like the ARMY's Multi-Million Dollar MMO project - but one guy with your guys help I don't play that game though - don't want to get depressed I want mine to be all original. I loaded the DarkMatter Tank - and Thought - I HAVE to make that thing come to life!

(Check out the link on my sig - it has a lot of various stuff I've done so far)

And please shed some more "LIGHT" on this subject if you can

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 19th Dec 2007 17:05
What I'd do to start with is use SET OBJECT LIGHT to disable lighting on your terrain, so it's fully bright. Then ensure that the mesh supports vertice colouring, most memblock terrain methods will do that already. Now for each vertice in your terrain, you could simply work out the slope, say take the height of the vertice, then check the height at 2 tiles diagonally from it, and work out the difference between them. The greater the distance, the darker you make the vertice colour. Just going by brightness you could limit the value to 0-255 and use it in each RGB component. Really, if you add different coloured lights then you have more work to do - this is just the basics, it's kinda like making your own directional light system, and is the best place to start. I would suggest storing the lighting in it's own array, because you might want to add shadows, smooth it out, etc etc. If you go for vertice coloured underwater bits as well, then having the shading stored seperately is very handy, like you'd just need to work out the depth, make the colour more blue, then use the stored terrain shade as a multiplier.


less is more, but if less is more how you keeping score?
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 17:47
Wow - I Almost get that 100% - In that (now) I need to figure out how to do the Light "source" from Any Angle That should allow full time of day - and night.

Though - I think the method I'm using NOW (light source Base) would be best (MAYBE?) for things like "Dark - and have flashlight". Hmm.

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 19th Dec 2007 21:30
actually this method is better than the vertex method. I might work out a demo for this.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 21:55
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 19th Dec 2007 22:23
Quote: "
What I'd do to start with is use SET OBJECT LIGHT to disable lighting on your terrain, so it's fully bright. Then ensure that the mesh supports vertice colouring, most memblock terrain methods will do that already. Now for each vertice in your terrain, you could simply work out the slope, say take the height of the vertice, then check the height at 2 tiles diagonally from it, and work out the difference between them. The greater the distance, the darker you make the vertice colour. Just going by brightness you could limit the value to 0-255 and use it in each RGB component. Really, if you add different coloured lights then you have more work to do - this is just the basics, it's kinda like making your own directional light system, and is the best place to start. I would suggest storing the lighting in it's own array, because you might want to add shadows, smooth it out, etc etc. If you go for vertice coloured underwater bits as well, then having the shading stored seperately is very handy, like you'd just need to work out the depth, make the colour more blue, then use the stored terrain shade as a multiplier.
"


Not to be negative but what you describe is basically re-creating the existing lighting framework. First, if turning off lighting makes your scene render 20% faster you need to upgrade hardware.

Calculating the "slope" of adjacent vertices is precisely what a normal is. A normal is a vector perpendicular to adjacent vertices for a given triangle. Then you describe calculating a vertex color based on the "slope" of these vertices. That's what the normal is used for in the built-in lighting framework! For those that don't know, lighting is calculated by:

Light = dot( normal, light vector )

That is the most basic lighting equation. If you store vertex colors you can multiply them by the light amount calculated above to get correct lighting. Shadows on terrain are best done with lightmapping (static) or using normals (realtime). These are tried and proven methods that give the best results for the lowest cost and least effort. I don't understand why you are suggesting to re-construct an already existing (and much more versitile) system.


If you want a new system that would allow you much more control and detail, I suggest learning about shaders. Then you can have per-pixel lit terrain with texture splatting. I'd be happy to guide you and share some code.
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 19th Dec 2007 23:21
I said:
Quote: "this is just the basics, it's kinda like making your own directional light system"


Quote: "These are tried and proven methods that give the best results for the lowest cost and least effort."

Best results? - You don't think built in lighting is fairly unrealistic?

What's wrong with using vertice colouring for shadows, why should it cost more processor power and graphics memory just to have basic shadowing on a terrain. How do you suppose he calculates a lightmap with a memblock terrain?, and one that he wants to deform?

I suggest he comes up with his own because clearly he's tried so many methods.

Quote: "A normal is a vector perpendicular to adjacent vertices for a given triangle"

No, not in the case of memblock matrices, in this case each vertice has it's own normal that should be calculated based on a grid, not the polygon normals that the vertices make up.


less is more, but if less is more how you keeping score?
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 19th Dec 2007 23:54
Quote: "
Best results? - You don't think built in lighting is fairly unrealistic?
"


Not in the least. What's unrealistic about it?

Quote: "
What's wrong with using vertice colouring for shadows, why should it cost more processor power and graphics memory just to have basic shadowing on a terrain. How do you suppose he calculates a lightmap with a memblock terrain?, and one that he wants to deform?
"


There are many articles online about calculating a lightmap for a terrain (instead of using a pre-generated one from 3rd party software). It's actually not slow but I wouldn't consider it realtime. Deformation of terrain (on the scale I imagine his game having) would barely affect the lightmap.

Quote: "
I suggest he comes up with his own because clearly he's tried so many methods.
"


He's just begun his work on heightmapped terrain and lighting and there are plenty of methods left to try if he were up for doing research on the topic. Given that he's writing a game - and not a thesis - I'm only suggesting the tested methods that have been proven to work and require the least amount of effort.

Quote: "
Quote: "A normal is a vector perpendicular to adjacent vertices for a given triangle"

No, not in the case of memblock matrices, in this case each vertice has it's own normal that should be calculated based on a grid, not the polygon normals that the vertices make up.
"


The singular of vertices is vertex, not vertice. You just affirmed what you quoted. A normal is a vector perpendicular to ajacent vertices for a given triangle. You mentioned calcuating the normal based on other vertices in a grid (adjacent vertices, mind you). You say "No" then repeat what I wrote in different words? I understand you are assuming I'm referring that every normal is in reference to a polygon - and I am. In a terrain you calculate triangle normals, then a vertex normal is calculated by averaging all the normals of triangle in which that vertex is a part of. Without using these triangles (or their edges which is what you mentioned by saying "other vertices in the grid") it is impossible to calculate an accurate vertex normal.
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 20th Dec 2007 00:08
Quote: "In a terrain you calculate triangle normals, then a vertex normal is calculated by averaging all the normals of triangle in which that vertex is a part of."


Ok, so explain how you would do this with a memblock terrain. Considering the vertices are added in sequence, everytime you create a vertex you need to set it's normal. You could make the memblock, then go through it again, grabbing adjacent vertice data and working out normals, but that's very complex compared to simply calculating the normal based on a height function. Rather than worry about adjoining vertices, I'd use a height function to return the height of any point on the terrain, that way vertices in the same location get the same normal, no need for slow recursive checks to average out normals. It's just the easiest way to work when making memblock matrices.


less is more, but if less is more how you keeping score?
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 00:25
Wow - I'm surrounded by veteran terrain people!

Hi Guys! That was an interesting read - and boy do I appreciate everyone trying to help me and discussing techniques!

So basically - It looks like there are a couple techniques then that could work:

1: Hardware Lighting (I guess we worked through that one now - as it works and I released the Test working code and media).

2: Vertex (Manhandled) lighting - using Vertex Color (and I suppose the "Normal" values for intensity..(Will try a Poly Test where I can play with all the "variables real time" soon - so I can "See a Normal" AND the reaction of "wiggling the vertex normal flagpole" - At minimum I'll have a good "How Normals" Work with/without "hardware light

3: The Stretched "LightMap" Trick - Takes UV Coord Understanding and a little mastery I imagine - Blurring it etc to get that natural look (BAsed on what I see some editors do and that many light maps seem small compared to "terrain" and are stretched - I think Blurring "helps" Though in DB I don't see how to over lay a light map over the base texture for a terrain model... and if I loaded one in a directx - I don't know if I could "edit" layer two programmatically (shadow layer) Be cool if I could get multiple layers without multiple layers of poly.

4: Learn How to effectively use Shaders for Per-Pixel Lighting.(Want that Hacked GG shader ... ... I should hack it myself I guess so I learn something about shaders.

WOW - I definately feel like this game stuff is as hard as a thesis.

Well - All I know is that without you guys - I wouldn't be as far as I am! You guys Rock! I Think I'm going to try to make the sun move around - so I can see how it looks - "Dynamically" - because even though it's dynamic this moment - I doesn't seem to much different than a static light/shadow map ... but I want to see the sun(light) move and the "Reactions" to it

Thanx a bunch.
Best Regards,
Jason P Sage

jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 00:30
Van B
Quote: "I'd use a height function to return the height of any point on the terrain, that way vertices in the same location get the same normal, no need for slow recursive checks to average out normals"


I have that in the down load. I also made ones to Write. But there is a lot of "stuff" to do these writes. I definately see the value of having my own "Datastructure" in memory and using that for manipulation - and then "Sending it" to the Mesh when I'm done. I haven't done that... but I DEFINATELY think its the way to go - for sheer speed's sake.

I mentioned this technique in a mesh related post in DB forum somewhere - that this technique also gives you some interesting options. Like "Healing the Ground" in this case and Restoring the "Colors" to how they were initially after a battle if necessary - but more likely and more kool is - image a game ... what was that game with the walking "Battle" Robots?... Imagine having a banged up from battle MACHINE get "RESTORED" with animations of workers etc.. Or Cleaning off a dirty face with water... Pretty neat stuff!

Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 20th Dec 2007 03:35 Edited at: 20th Dec 2007 03:47
Jason-
Per-pixel light is easy with a shader. What I am wondering is, are you expecting inter-reflections? You know, like if the sun is off to the left, will a hill in front of the sun cast a shadow onto another hill? If so, then, even per pixel won't do it, unless you modify the normals that are in the shade, because those normals have no idea what the other normals are. Lightmaps will work, but lighting won't be dynamic, unless you make alot of lightmaps. Pre Computed Radiance Transfer is the technique to calculate inter reflections; I read about it on MSDN, in fact, I asked about something like this on the shader thread BEFORE I even knew what it was (saving output from shaders). Apparently, there is a way to use a shader to preprocess things to speed up the real time stuff. When you see their examples, its gonna make your mouth water .
In my situation, I just calculate the normals AFTER I deform the mesh. I just let set object normals() do it, and, the pixel shader does the rest. I still want to cast shadows from the hills for more realistic lights, but, thats going to take some more thought.

Edit:

Here is a simple per-pixel shader I've been using for testing. Takes in 2 parameters, a float4 vector for the light pos (Float3's don't work in DBP. Just don't set the W to anything), and an integer val from 0 to 100 for ambient light %
Wrote for ps 2.0, but should work on lower, just change the value in the technique section if you don't have a 2.0 card.

edit again:
Also, with that shader, its real easy to make the sun dynamic. In fact, that last demo I put up does it, the one I'm working on now does it even better. I'll put it up tonight.

Attachments

Login to view attachments
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 20th Dec 2007 03:54
Quote: "
Ok, so explain how you would do this with a memblock terrain. Considering the vertices are added in sequence, everytime you create a vertex you need to set it's normal. You could make the memblock, then go through it again, grabbing adjacent vertice data and working out normals, but that's very complex compared to simply calculating the normal based on a height function. Rather than worry about adjoining vertices, I'd use a height function to return the height of any point on the terrain, that way vertices in the same location get the same normal, no need for slow recursive checks to average out normals. It's just the easiest way to work when making memblock matrices.
"


With a memblock terrain I would loop through the vertices and use the vertices to the -/+ X and Z to calculate four normals (treating the adjacent 8 triangles as 4 quads) and average them to get the vertex normal. If I was feeling really ambitious I might go for 8 normals and average them. (That would be all the triangles that share the vertex I'm processing)

This would be done with 2 loops, no recursion. It's quite fast.

I hope the "height" function you're referring to is actually a "get height of nearest vertex" function. Otherwise the approach you are describing would be much more computationally expensive than averaging some normals.


@Visigoth:
Here are some links in reference to terrain self-shadowing. They're simpler methods but perhaps more cost-effective.

http://www.gamedev.net/reference/articles/article1817.asp

http://gpwiki.org/index.php/Faster_Ray_Traced_Terrain_Shadow_Maps#Algorithm

http://www.gamedev.net/reference/articles/article2125.asp

and check out the links here:
http://vterrain.org/Performance/lighting.html
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 03:59
Hmmm... Interesting. I'm thinking Light Maps Might be best... (inter-reflections?) ...casted Shadows etc. I also did some reading online today about various foliage techniques - and - well - I think in that dept. I will need to implement multiple "Techniques" for various Perspectives - Flight Sim'ish - Vehicle/FPS'ish - and may [F]ace In Mud.... The FIM Effect (The true measure of FPS greatness... )

I have a question. If you Scroll up and see the shots with the "Shadowing" and the "Sphere sun"... Well.. I did what I mentioned in my last post - that is - move the sun around... and my question is:

Should Normalized Vertices "Change" as I move the Light around? I set up some pretty straightforward code to move the "light" Around. And the Shadows Didn't "Change" with the Sun at all!

Aren't they supposed to? TParkin said this was real time.

I tried a bunch of different Light Settings, Object Commands - Ambience - Is there a combination of commands I should set for my light and my Terrain mesh before moving the light around so the normals do what I thought they should?



Well - I'm currently cleaning up some "General GDK" OOP stuff I have - and I'm integrating it with this test "MemBlockMesh Test" app - in preparation for Frustrum Culling. After Looking at LIT's Code closer - I need some of my classes to make Frustrum Culling totally dynamic - So you can Add Objects and Remove them at will. I think I may be able to 100% integrate it to the rest of my oop stuff in a manner that will be pretty efficient... Rather than adding it to my Object List (which could be huge lets say) - I'll have a separate linked list just for FRUSTRUM Stuff - So You just Tell the Frustrum list Which Object You want to add to the list - and then I'll make it smartenough that if the object is deleted - it gets ganked from the FRustrum list as well

So - I think I MAY have to write a more "Texture" Applying routines - and I definately want the ability to Paint my terrains how Van B is doing it - or maybe some other shader way.

I think I should be having some decent Terrain and culling all working together soon - and the USGS is now a gimie - I mean - its just neat.

I REALLY think I might be able to pull off a ROAM for USGS data - but for now I'll stick to this approach - for the Flight Sim effect - (I'm not ready for showing "Roundness of earth like MS flight sim or anything yet)

So - the question stands: Should Normalized Vertices "Change" as I move the Light around?

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 20th Dec 2007 04:47
they should stay the same once set. I can see no reason to change them.
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 20th Dec 2007 05:10
@tparkin
I'm going to pick your brain on this sometime, in more detail, if you don't mind. It'd be nice to get even more acurate normals. Thanks for the links, I will read them.
@Jason-
Normally, no, the normals don't change, unless you change the mesh, like blow a crater into it or something. But once you have your mesh deformed, then you set your normals. tparkin is mostly saying that you can get more accurate normals for a vert by averaging against the positions of other triangles that touch the same vert. I don't know how deep the built in command goes, but, I know I really want to do this myself. If you want to see realtime lighting changes, my demo is done, I'll post it in my terrain thread.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 05:24
Thanks David W. and Visigoth.

I THINK I understand TParkin's 4 vs. 8 Vertex deal.. And I also understand that the Normals are just a variable - and "They" don't change - but I thought if I moved my LIGHT Zero Around - I'd see the shadows "move" in relation to where the light was - real time.

I'm currently getting nothing when I move the light around - except I see the Sphere I'm using move - but the shadows don't change - this is what I meant. I thought it would be real time.

and I'm asking if there are a combination of Dark Commands that I can Call for Light Zero, and my terrain object - to MAKE SURE that this "Real Time" Lighting can be seen... when I move the "Sun Around".

So - should I be able to see the shadows "change" if I move the light Around?

Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 20th Dec 2007 05:53
Jason-
See my demo in the USGS thread. You WILL see the shadows change. Its not hard to do!
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 17:05
Well - as my PC is just to old ... I can't get to the house unless I walk/fly for 5 min

Scope this out - any one - This little DBPro snippet moves "Sphere and light" - and the test cube doesn't change (surfaces don't seem to acknowledge the light at all...Looks like the light isn't moving at all!)



tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 20th Dec 2007 19:12 Edited at: 20th Dec 2007 19:24



Try that code.


In order for your "shadows" (really dark spots, not true shadows) to adjust in realtime you don't need to modify your normals. The normals will only change if a surface is deformed. Light amount (how bright or dark a surface is) is calculated by the dot product of the normal of a surface and the direction vector of the light. This means that as the direction of the light changes, the amount of light hitting the surface will change. So no need to change the surface normal.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 19:39 Edited at: 20th Dec 2007 19:47
Quote: "In order for your "shadows" (really dark spots, not true shadows) to adjust in realtime you don't need to modify your normals."


I understand this - (I think) - I Think this way (Correct me if I'm wrong please)

1: Adjust Terrain Vert positions (Heights whatever)
2: Calculate Normals (Figure out Poly Angle, Calc the Normals, Avergage adjacents for a none faceted look)
3: Move light around and you SHOULD see the light have effect on terrain.


I understand setting normals sets up the "Rules" to how light will hit that poly - from then there out. I'm going to try the code snip you provided. already though - the color light 0,0 makes me think there lies the root om problem.

Maybe I can't move light 0 around? I'll hush now and just go try it thank You.

You seem to kill light 0 by setting to black - THEN make a light 1 - and move that. THAT seems to be the secret. Now I'm off to go test THANX AGAIN Code snip seems to say it all.

[edit] Yup - that's hot and What I expected all this time. So - Point Light - Is that the recomended way to do a SUN for the terrain? I did that for flashlight and I did cone light too - I thought NON-POINTY lights still had "Direction" from their source ... just pointing everywhere "Outwards". This SEEMS to have brought into question. Well... I'll go lose the point light thing in your code ...and...it.... Works Also. Hmm... The Verdict:

Light ZERO Stinks
Light 1 is Cool

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 20th Dec 2007 19:45
I don't use DBPro so I don't know any special rules about light 0 but experienced some troubles while writing that code and decided it'd be best to just turn off light 0 and stick with light 1.

The steps you listed for lighting terrain are correct.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 19:48
Check my Edit tparkin - you posted while I was editing my "final findings... in short Light Zero has been my problem.

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 20th Dec 2007 19:51
Thanks. Yes, light 0 is probably a special global static light or something. I use an ObjectFactory in my DarkGDK so I never have objects (or lights) with ID 0 and therefore would've never encountered this. Good to know.

For a sun you would want to use a directional light. Point lights are more for things that emit light in all directions (torches, etc.)
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Mar 2008 02:14
TParkin - where ya Been? I think you MAY have had that code snip dead on - I noticed today the importance of the poly order.

I'm still fussing so I'm not sure 100%... As soon as I clear up a SEAM "Crossing" issue with the normalization (Which has been accounted for but is flawed ... somewhere I goofed)

Anyways - Still messing with normals. Trying to get this Terrain/Mesh class I've been pounding ready for an editor of sorts.

Well.. See ya round. Haven't seen much of Tempicep either

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 9th Mar 2008 04:06
Hey Jason,

I've been quite busy lately. How's your terrain coming? What issues are left to be resolved?

Let me know how I can help.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Mar 2008 14:14
I appreciate that offer. I'm in quite a deep hole to ask you to climb down - I didn't leave a rope anywhere around!

As you may know I switch to DarkGDK for this game and since released the DBPRO code as it sat un until that point - not finished - playable - and alot of people have scoped it out now.

The good thing is aside from the fact its not done - people generally liked it: http://forum.thegamecreators.com/?m=forum_view&t=124752&b=1

But that's Advanced terrain... Back to topic here... I am on my second GDK rewrite of a base code library to build the game on. (David W convinced me that MAYBE I should revisit my Double Linked Lists. they are awesome but not as fast as arrays and at first I was reluctant but some benchmarks convinced me to switch to a dynamic array based system and use Double Linked Lists where they are simply superior... like constant adding and deleting of items for example, or a menu system list of stuff where PURE speed isn't required.

The terrain I originally was having a problem with didn't have welded verts and also had a simple two poly per square cell layout.

I'm currently using a poly layout and welded vert system based on how Visigoth built his USGS terrain. I took that core design, and turned it into a complete class that allows you to access terrain like a DBPRO MATRIX, except it is made of user defined X,Z of OBJECTS, User defined X,Z Limbs Per Object, and user defined X,Z CELLS per Limb (must be even numbers:2,4,6,8,10,12)

Works Awesome, except I applied an old MATRIX normalization routine and its fine, but when I applied your logic, its flawed at the limb seams EVEN though FINE in the limb.... And the weird thing is the SAME code does the vert settings, and it works fine where these normals act weird (So I THINK I'm reading the info correctly, and accounting for adjacent stuff).... hence my dug myself in a hole quandry.

Part of me REALLY wants to go back to NON Welded Verts because it seemed like you have alot more control - and can choose between flat shading or this averaging thing I'm doing now.

I think the code you gave me is fine, and trying to ask you or anyone to code review a 500 line routine, which uses sub functions on top of it is WAY to much to ask.

But I can Show you a pic (Attached) of some of the results as of late. (I'll do a couple posts so I can upload the pics)

Thanx for your response - hope to see ya around again!

Best REgards,
Jason P Sage

Attachments

Login to view attachments
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Mar 2008 14:15
(Another Pic - this time textured and sky'd a little)

Attachments

Login to view attachments
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Mar 2008 14:18
(Last one - I which you could upload multiple images without a host and have them show in the message body in the forum )

This pic is the non-welded vert mesh I have - its only one limbed object. Programmable, but not a checkerboard of objects in one class which is better for frstrum culling

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 9th Mar 2008 15:55
Quote: "Part of me REALLY wants to go back to NON Welded Verts because it seemed like you have alot more control - and can choose between flat shading or this averaging thing I'm doing now."


Yes, however you only need that extra control for certain objects - or parts of certain objects. For things like terrains, welded vertices are probably more efficient - unless you want sharp edges on things like cliffs and rocky outcrops.

For objects like crystals, diamonds, cubes, etc, welded vertices would be useless for lighting - unless you used a specially constructed normal map. I don't know what the performance trade off is like, though.

Interesting thread - managed to miss it first time round.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Mar 2008 16:36
What you say is very true GG.

I think to really leverage non-welded for terrain you would need a "Terrain Editor" that allowed you to select polys individually (or in gorups) and flag their behavior as "Averaged" or "Individual"

Also, it your poly count is kinda high, you should be able to come pretty close with the averaged welded stuff.

I've done some tests and can confirm that my routine that sets the NORMALS based on simple x,z in the terrain is spot on.

Each individual CELL really is a two poly square, I just made a pattern where the "Diagonal" alternates per Visigoth's suggestion.

VanB mentioned a recursive Normal Averaging thing, I didn't go that route... I used the MOD operator to determine Which way the diagonal was going... So I could attempt to gather the vert info for a given poly correctly is pass on, and in pass two, I use this to aquire all the normals adjacent to the vertex in question for averaging... I did it in two passes...

Pass One: I made a memblock that stores 2 Normals(x1,y1,z1, x2,y2,z2) per cell. After I calculate the two normals based on the verts for each triangle (again...2 per cell) they are stored for Pass2.

Pass 2: The code's logic figures out what normals are adjacent to the current vert in question, and adds them up (Each time it finds one) and I also increase my iDivideBy variable for the actual averaging once I find them all.

This runs amazingly fast considering some of the meshes (groups of meshes really) I toss at it.

I am convinced its a poly vert ordering thing or something buried in the math to get a normal based on 3 Vert X,Y,Z positions.

I'm aware the order (winding) of each poly can make or break it - but I get a Pretty much identical output for all the polies except the seams - which again - I can turn the terrain ALL DARK or LIGHT (no seams) by jammming in normal values like 0,1,0 or 0,-1,0 or whatever without seams... so it must be the math or maybe still the logic to grab the correct adjacent verts.... Still fighting.

Not how I wanted to spend my weekend! But I can't move forward without satisfaction its "Good Enough" -- It's not Good enough yet and the retro fitted DBPRO MATRIX normalization technique... well.. just doesn't look like right yet.. though I fogot about that light Zero thing... maybe I'll try that alittle two.. meaning I'll hide light Zero and make a light for the Sun myself again.

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 9th Mar 2008 18:01
@jason

Sounds like your making progress on this. The screens look awesome. I've been kinda sick all weekend and I hope I feel better by tomorrow for work. So I havent got any coding done on that demo I promised you. I will try to get some work done on it over the week.

I think Iron Infantry is gonna be one of the best games to ever come out of DBP/GDK. I like your style. I know the GDK version is gonna blow that DBP stuff away. Well anyways, good luck.
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 9th Mar 2008 19:48
Hi Jason,

Thanks for the pics. It's looking good.

Arrays vs Linked Lists are only an issue if you are adding/removing often in your game loop. I would think this wouldn't be the case for you, since you initialize your terrain and then it's "done". Unless you are using some partioning system like a QuadTree, then I can see the need to switch to arrays (to keep objects in individual nodes). I haven't really read much of the thread in quite some time, so I can't say for sure about your situation.

I have two questions.

1) Is there a reason you are not using shaders for texturing and lighting? I wrote some terrain code long ago that uses shaders for lighting and would be happy to share it after I revamp it. I'm going to be re-coding it in about a week for the project I'm working on with DarkGDK so if that would help to see it I'd be happy to do so.

2) Can you please explain your terminology of "welded vertices". I think you mean that the vertices are stuck in their x, y positions, but not z? (To be used as a DBPro matrix) It sounds like you can light one "chunk" of terrain fine, but when you put several "chunks" (perhaps they are limbs in your system) next to eachother, they don't line up in terms of lighting. Is this the case? If so, I've done this before and can provide some insight.

Let me know!
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Mar 2008 20:34 Edited at: 9th Mar 2008 20:54
@David W - Wow! Thanx! (Now I have to live up to that... LOL )

@tparkin -
Quote: "1) Is there a reason you are not using shaders for texturing and lighting?"


1: Hardware Lighting + DBPro/GDK Fog work Together nicely.

2: Shaders Require Correct Normals Just as much as Hardware Lighting - It helps the routines that use the normals to decide something - like what texture or how much of one to blend etc.

3: Shaders + Global Fog Looks Terrible. Poly artifacts as terrain comes into view... YUCK.

Quote: "would be happy to share"
Most Awesome. I've actually got everything down except the normals. This particular routine is complicated by the fact that multiple objects, multiple limbs, and mulaiple faces per limb, all need to adjoin seamless. I've done it for the vertex positions, placement, ground height works, heightmap or USGS files (Loads them natively...the gridfloat format) and all is great.. Except the normals.

Quote: "2) Can you please explain your terminology of "welded vertices"."


Sure. Jason's terminology: Welded Vertices = Vertices that are shared by multiple polygons to conserve resources, and also simplfy making deformable terrain (By changing ONE VERTICE... Multiple Poly effected because they share EXACT same vert)

Quote: "I think you mean that the vertices are stuck in their x, y positions, but not z? (To be used as a DBPro matrix)"


Well kinda but my "Class" to control this mesh allows moving verts any direction on any axis. For basic, I just play with the Y or Heights of each vertice - but I hope to eventually be using it all Example: Explosion? Deform and Burn terrain! Maybe catch folliage on fire, smoke particles etc.

Quote: "It sounds like you can light one "chunk" of terrain fine, but when you put several "chunks" (perhaps they are limbs in your system) next to eachother, they don't line up in terms of lighting."
Well.. this function I've been working on ALL WEEKEND looks that way... and has sent me chasing my tail... How do I know I'm chasing my Tail? Because I got fed up with the three vertice x,y,z to FACE NORMAL calculation, and replaced it with something kinda odd.

I have a version of this function using My Sparky Based GroundHeight Function (offset so ray cast lands dead center in the polys) and then I query sparky's normal collision values, divide by two (because the ray shoots straight down and I suspect the normal is a combination of the ray + terrain hit)... anyways... this comes out PERFECT. The averaging, no seams.... I'm a bit perplexed by the whole affair now though.

Scope this out! This is using Sparky's to gerate the normals... I take that and divide by two.. then the rest of my function does everything perfectly - included the averaging I talked about etc.

so Somehow the code you gave me, in this situation is either not working, my vectors are screwy or something (I tried various vertex ordering and you mentioned the subtract order might be hosed, but I compared to someone elses code and the only thing that was different was the final normalizevector in the pvt_GetNormal function):



Looks MESSED UP.... But this... using Ground Height functions, Raycasting Collision normals / 2 - Works Gorgeous... I'll attach a Pic.




Pic Attached.

[edit]If you looked at second code snip before this edit - you were looking at the same snip pased 2 times... sorry... I was IM'ing with another developer during this post and lost my train of thought... My Apologies. Especially if you were gawking at the code for awhile perplexed![/edit]

[edit2]Concerning Shaders - Did I mention shaders drop my frame rates as much as 50% or more? Thats another reason I'm not struggling to get a shader based scene going. Wouldn't be playable. I'll use the hardcoded FFP shader for now that GDK uses.[/edit2]

Attachments

Login to view attachments
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Mar 2008 01:13
I Figured it - however the Sparky's one still looks a HAIR better then by math derived normals.

It was the Vertex Positions. They are recorded in the Mesh as still being where they were originally created. That threw everything off that my code expected. This is why dropping in a GOOD normals into the rest of my complex 2 pass Normal Averaging routine Worked.

UGH. So Now - this moving the Terrains around... like having multiples, is going to requires a little work should I elect to have the ability.

Well - I think I got it. See Attached For The Record - loud and clear: TParkin's Maths Are good!

Thanx Everyone who Helped!

Best Regards,
Jason P Sage

Attachments

Login to view attachments
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Mar 2008 01:37
I couldn't resist ONE more Screen Shot with the Cam Range Set a Little bigger than normal

Attachments

Login to view attachments
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 10th Mar 2008 02:02
I realize I'm fairly new to DarkBASIC, but I was looking into shadows as part of my requirements when I purchased DBPro, and this little code snippet came from somewhere in these forums. It's what convinced me that DBPro was able to provide what I wanted.

Now I suspect this is shadowing from the built in system you guys have referred to as inadequate, but I can't find much wrong with it yet. At least not from this little demo.



Maybe I'll find more wrong with it when I've got it lighting up a terrain. I don't know yet. I thought I'd post it in here if it helps you, if not maybe it will help someone else researching the same subject.


It's a big universe, and they are out there somewhere.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Mar 2008 02:41 Edited at: 10th Mar 2008 02:47
Well Buddy - Glad you stopped in - and your heart is definately in right place - glad to have you aboard.

Now Sir, the shadows to which you describe are a built in shader, and as such - for me personally - kills my frame rate like a crying baby can ruin an intimate moment for it's parents!

Now that ALONE has made me not to hot on the shadows...but I need shadows, so I will eventually mess with it more to see if it jives well enough for my game, tune it, and make it an option the user can switch on. this way if they have the horse power (which I don't) they can enjoy it.

Now as it pertains to this thread, I am working on something a slight bit harder than just flipping on a shadow shader.

Polygons (Triangle variety) which make up our 3d images can be created a number of ways, in that there are different formats in memory that are used to describe them. Some only have the position of each of the points (vertex or vertices) that make them up. Others store that as well as "Diffuse" color information on each vertex. (Follow my sig to the IronInfantry Photo Gallery and see the rainbow quily matrix I did while learning memblock meshes )

Most also store information on how to present a texture, which is data at each vertex. These are called UV Coords - a 2-D thing draped onto a 3d surface. Some even allow as many as 8 textures to be represented - (8 sets of UV coords! This is how shader's can use so many textures on one object - the shader picks and chooses which, when, blends etc per pixel)

Last but not least... we get to LIGHTING. Lighting, like vertex positions, have an X,Y,Z set of coordinates on each vertex. These have a value from -1 thru 1 and making these values within that range is often called normalizing them. They describe a direction and the anaology that worked for me is they are little flag poles sticking up out of every vertice. the magic is with hardware lighting (And shaders can use these values too to decide things while rendering). The angle a light ray intersects with these flagpoles changes how that VERTEX responds to Light.

So, with some careful planning, and some math, you can adjust VERTEX NORMALS to react to light how you want. Now there is something people refer to as a face normal... that is X,Y,Z that describes (-1 thru 1) the direction a POLY FACE is pointing. So a POLY FACE NORMAL is ALWAYS Exactly STRAIGHT AWAY from the Poly, a 90degree angle perpendicular to it FLATNESS. (Forgive my non mathemitician descriptions.)

What this whole thread is about is a BRAIN TWEAK called NORMALIZING NORMALS - which contrare to what I just told you (NORMLIZING means making values within -1 thru 1) means MAKING the VERTEX NORMALS coincide with the "imaginary" - must calculate yourself usually) Poly FACE Normal. By setting all 3 vertex to the POLY FACE NORMAL, the poly will darked when its not facing a light, and brighten when it is.

If you do this to a whole mess of polys - you get a faceted look as the light moves around - e.g. Green Gandalf mentioned how a LIGHT reflects off a diamond. This method is called FLAT SHADING.

Now having a ton of poly, means triple that in VERTICES (lots of mem adding up) so there is a technique you can do called WELDING VERTs. This is where you make the 3d Engine allow LESS poly's to exist in memory by making adjecent polys in a model SHARE VERTICES that are in the EXACT same position.

Because there is less VERTEX - you Save Memory, and its more efficient for the 3d renderer. NOTE however that we now have less info to describe each poly individually, THEREFORE - our flat shading trick wont work because we no longer have 3 vertex per poly to decribe the LIGHT NORMALS' NORMALS (confusing I know) as all pointing the same direction.

This leaves a slight quandry that can be resolved by more or LESS by calculating the POLY FACE NORMALS (directions the adjacent polys face) and then adding them up and dividing by the number of polys sharing that vertex. (Average them!) This loses the FLAT SHARP Shading but you gain a softer darkening/lighting effect.

The import thing to remember wrapping this all up is that even though the whole point is to have the lighting look correct, we are NOT CASTING SHADOWS... we are just making poly's draw darker that don't have a light right on them.

They look like shadows (which is what I want) but they don't help CASTING a shadow - for example one hill leaving a shadow on another.

Phew.... I wouldn't write that book if I did think you were cool!
[edit] <<---- Oops ..Ahem...Didn't THINK you were cool ..Sorry [/edit]


Welcome to forums.

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 10th Mar 2008 02:49
Hey Jason,

Looks like I missed the excitement, but I'm very happy you've got it! The results are astounding! Excellent work.
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 10th Mar 2008 02:51
Hey Jason,

It seems like your beef with shaders is the fact that the built in DarkGDK shaders suck. (Correct me if this is wrong).

I will agree that the built in shaders suck. I would argue that writing some basic shaders yourself will dramatically improve frame rates, granted you have a compatible graphics card.

On this note, I'd suggest looking into shadow mapping for doing shadows.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Mar 2008 03:39 Edited at: 10th Mar 2008 03:45
Thank You TParkin - Thanks for Your contribution. When I got down to the Sparky Freaky Test and it rendered like I planed I was Like - ITS THE MATH! But it Wasn't the math... it was the Data I pumped through it LOL... The WHOLE Weekend because I didn't take into account that asking for a POLY "One Tile North" Could ACTUALLY MEAN Five Tiles south because the original mesh design for each limb is a carbon copy of the one created at location 0,0,0.

I'm wondering if it would be worth it to REDIGN the MESH Creation algorythm to take into account the EVENTUAL placement of the Meshes so that the VERTEX positions are GOOD fodder for the actualy Normalization - this way the sparky way and my funnky (but functional also like sparky) "Calculate where the poly WILL BE PHYSICALLY" trick. I'd rather have the POLY be smart enough to just report where it is in the world... but I have to be careful the frustrum still works right with such big offsets... No to mention the enemy of all huge terrain: SEAMS! LOL

Now about the shader thing. I think you're spot on about their speed etc etc. You know who is good at writing efficient shaders? Visigoth! He spends alot of time trying to make them faster. Green Gandalf has got some killer ones that we all use around here - for fun, and I bet by now, some are "Built Into" some games in production!

I know what shaders are, and I'm still in new territory with C++ relatively speaking - not to mention DarkPhysics and DarkAI I've yet to crack the binder... um... So yeah - I know about how shaders CAN work.. But I think the real deal is I need a faster PC but I don't mind developing on a slower one as it makes it less acceptable to have bloated code, dumb rendering techniques, and shader overkill

One of the things I slated myself to get to - not done yet but.. is a Shaderless Shader - which basically will allow me to HOPEFULLY do a certain amount of texture blending in a terrina editor or something without trying to do alpha mapping or someother GFX card killing technique. I also think I'm going to go the Burned in shadow look maybe.. for trees, building etc... and I mean literally burned in, not shadow mapped.

How do I expect to getaway with this? By Making user settings on max cam range, and the frustrum system smart enough to deal efficiently and the sky and other stuff to "adapt" to the max camera range etc.


Ok - now - without further adeu - the screenie my wife thought just needed to be on here.... the FOV is cranked up, the USGS satelite information is TO SCALE.... This is a window into the future of how terrain will look in Iron Infantry if I can get it stay looking like this, while adding AI, folliage, etc. P.S. Clouds are moving I wish you could see!.... It took 10 minutes for this test application to create this scene before I could fly around in it!

[edit] 10 minutes???? Yeah, its over 20 miles square, and I haven't made an editor to save out DBO tiles yet or anything...plus the whole slow pc thing. There is approximately 3 to 4 million poly hidden in dem dar hills... Without Frustrum culling, it wouldn't work.[/edit]

See Attached. Make sure if you see in a browser to click it so it goes full size.. other wise you can't quite see the depth of this pic.

Attachments

Login to view attachments
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 10th Mar 2008 04:02
Nice pics. I think I was writing my post while you were putting those up.

I guess I didn't read the questions completely, nor understand some of it.

Thanks for explaining all of that. It will give me something to look back at when I get things to that point. (which I'm hoping will be soon..)


It's a big universe, and they are out there somewhere.

Login to post a reply

Server time is: 2024-05-20 03:06:56
Your offset time is: 2024-05-20 03:06:56