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.

Dark GDK / Calculating VERTEX NORMALS .... I need a little help if you have a few

Author
Message
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 17th Dec 2007 22:18
Ok - I know so little here - and I HAVE searched and I have read - and I have done some experiments - but I feel clueless.

1: A Normal to my knowledge is just a X,Y,Z set of coords found in the data structure of a VERTICE.

2: A Normal "PLANE" (Like MyNormal.X for example - don't know correct terminology) can have a value from -1 thru 1. This Value Represents an Angle - I THINK it means it can represent -90 thru 90 - Where ZERO would be dead center.

3: A Normal Effects how Light works on said given vertice (area) of a poly. The greater the angle difference between the light source against a poly - when the normal "angle" is taken into account - the greater the angle (light to Normal Angle (which is effected by poly orientation to) - the more the light "effects" that part of the poly.

4: I read about Flat and Geroud(sp?) Shading and actually have an incling why they look so different and what it is - and why they look different.


Question ONE:
How do I calculate the normals for a given poly to do Flat Shading? (Just set them all to xyz: 0,1,0 ? Or it that only right if the poly is flat on the ground facing up and I should take into account the angles of the surfaces of the poly whentrying to calc the normals "1 thu -1" angle?) BTW: If I seem close - but you can toss a few samples or some pure psuedo -

Question TWO:
How can I "Average" 3 VERTEX's Normals? (Should help me do to Geround Shading if someone can help)

Thank You - Any Kind Soul who can help out here - I did very well looking at Rain-Man "Explaination" pseudo-code versus tons of code scanning and Wiki and demo studying.

All I'm saying is that sometimes if I understand "What" and "Why" with a few "pertinant" code snips - I can usually figure things out and be running - I'm really stuck here.

aersixb9
16
Years of Service
User Offline
Joined: 29th Nov 2007
Location:
Posted: 17th Dec 2007 22:32
Not to be annoying or snippy...I use dbLoadObject and let 3D Studio calculate my vertexes. Why on earth are you accessing vertices directly???
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 17th Dec 2007 22:50
Because I'm programatically creating Terrain like this from USGS Satelite Info - (or homemade heightmaps) and moving vertices around I think messes up the way you WOULD THINK the light should hit them.



Full Size:
http://www.jasonpetersage.com/img/TankGame41_HomemadeTerrainEngine.png

And you didn't sound Snippy -

aersixb9
16
Years of Service
User Offline
Joined: 29th Nov 2007
Location:
Posted: 17th Dec 2007 23:04
Wow, that's pretty nice looking. Good idea, generating terrain from public sat maps. That will give you some pretty realistic terrain!

I seem to recall from my C# Direct3D days that there's a function to calculate vertex normals in the DirectX SDK / API. I don't for the life of me know what it is, however! Sorry I can't be more helpful.
dbGamerX
16
Years of Service
User Offline
Joined: 23rd Nov 2007
Location:
Posted: 17th Dec 2007 23:40
That's beautiful Great start.

I'm not at vertex normals yet, so you're a good distance ahead of me. This page might help you though:
http://www.gamedev.net/community/forums/topic.asp?topic_id=355340
http://msdn2.microsoft.com/en-us/library/bb324491.aspx

dbPrint ( "Sig" );
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 18th Dec 2007 00:36 Edited at: 18th Dec 2007 00:54
Thank You for the Links. I read The Microsoft One earlier - that's how I kinda knew what they were - but even that wouldn't have meant as much if I was in the trenches changes vertex normal values and looking at the changes realtime.

That GameDev.Net Link - I kind of get - but when I see OpenGL commands - I don't know what they do - BUT I'm going to read it AGAIN - and look for DarkGDK equiv and see if I can't get something working.

Does Anyone actually have any code or something for this kind of vertex normalization? (still struggling) I'll post when I get this resolved - meanwhile... any takers

[edit] Thanx for the compliments too - didn't mean to seem gruff or unappreciative[/edit]

Pharoseer
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: Right behind you
Posted: 18th Dec 2007 00:51
Hey Jason,

A normal is a vector that is perpendicular to a surface. Sorta like a flagpole sticking up out of the yard.

I'm not sure how to calculate a vertex normal (I'll have to look it up). But I might be able to help you with the faces. I'll assume you're using triangles instead of quads at the moment.

First you need to get the vectors that define two of your three edges. So if you have a triangle ABC find the vectors AB and AC. To do this you'll just subtract all the elements in A from B to get AB and all the elements in A from C to get AC. Here's an example:

A = (0, 0, 0)
B = (1, 0, 0)
C = (0, 0, 1)

AB = <Bx - Ax, By - Ay, Bz - Az>
AB = <1, 0, 0>

AC = <Cx - Ax, Cy - Ay, Cz - Az>
AC = <0, 0, 1>

Now, to get the normal to our triangle ABC we need to get the cross product of the vectors AB and AC. The order we do this in matters because the is effectively a positive and a negative normal. We want the positive one. I'll skip the in-depth explanation and get to the practical stuff.

To calculate the cross product, simply do the following:

Let AB = P and AC = Q (makes the next part easier to read)

P = AB = <1, 0, 0>
Q = AC = <0, 0, 1>

P x Q = <(Py * Qz) - (Pz * Qy), (Px * Qz) - (Pz * Qx), (Px * Qy) - (Py * Qx)>
= <(0 * 1) - (0 * 0), (1 * 1) - (0 * 0), (1 * 0) - (0 * 0)>
= <0, 1, 0>

Which makes sense. Our vectors AB and AC represent the positive X and Z axes respectively. We already now that the positive Y axis is perpendicular to those.

Lastly, remember that order is important. If you follow the order listed here everything should work for you. If you reverse the order (say subtracting the elements in B and C from A instead of subtracting A from B and C) then the normal we get will point in the wrong direction. Also, it's important to notice that P x Q != Q x P.

I hope this helps and I hope I haven't been condescending or confusing. I'll look up the math for vertex normals and get back to you. It's probably not too much more difficult than this.

-Frank
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 18th Dec 2007 01:01
No - you sound fine - I have to roll up my sleeves - somethings I get right away - this I have to stare at awhile. I THINK I get confused when thinking about "vectors" I forget that if you break it down - its just 3 values (or depending on the vector type 4 or maybe more)

But I think I get that fine - let me start digging into it thoroughly - and take it in.

You mentioned triangle versus quad. Well - I used "Squares" - pairs of triangles - but I THINK the math remains the sames - as long as I just treat it the same way - I mean - triangles are triangles and I'm doing the same thing ... if I'm way off here - don't worry - I read enough to know if I have a bunch of triangle poly - I need to do this to every one - Normalize the VERTEX Normals - Average them - Get a "VECTOR" (Direction) then to the same to the adjacents and average them or something - its ok If I don't get it yet - I won't stop until I do (Except to figure out frustrum culling so my test code runs faster )

Pharoseer
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: Right behind you
Posted: 18th Dec 2007 01:54 Edited at: 18th Dec 2007 02:02
Hey Jason,

I think you are right about averaging the vectors. I don't know any shortcuts to make that easier though.

Also, I forgot to mention that for most purposes you want your normals represented as a "unit vector." Basically that's a vector that is 1.0 units long. Oddly enough, converting a vector to a unit vector is called normalization even though it has nothing to do with getting a normal vector.

Anyway, to normalize a vector you need to first calculate the magnitude of the vector. For a vector P the magnitude is:

m = SQRT(SQR(Px) + SQR(Py) + SQR(Pz))

(think Pythagorean theorem)

Then simply divide our vector P by m. The method for this is:

P / m = <Px / m, Py / m, Pz / m>

And voila! we have a normalized vector.

Here's a simple example:

P = <2, 0, 0>

m = SQRT(SQR(2) + SQR(0) + SQR(0))
m = SQRT(4) = 2

P / m = <2 / 2, 0 / 2, 0 / 2>
P / m = <1, 0, 0>

Again, hope this helps. I look forward to seeing your progress!

-Frank

[edit]
I just realized that I never answered your question about HOW to average 3 vectors. If we have the vectors P, Q and R the way to average them is as follows:

<(Px + Qx + Rx) / 3, (Py + Qy + Ry) / 3, (Pz + Qz + Rz) / 3>

That should do it.
[/edit]
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 18th Dec 2007 04:30 Edited at: 18th Dec 2007 15:07
FIRST - Thank You - I've been implementing your explaination all evening!

(Thanx for the Averaging update)

[EDIT] There is an attached Picture. The TOP half of the picture uses the Math Frank Provided. The bottom Picture - which obviously looks nicer is from a DBC Tutorial for making a "DB Flavor Matrix" have NORMALIZED VERTEX NORMALS - But I think its flawed as well.

I'm ALSO very aware that Frank's MAth is probably RIGHT ON and its something I am doing wrong - a bug - whatever.



But the results are nasty - I'm currently trying to see if I made any errors - typos now.

The Top Part - is after the above code (Your Math implemented - probably with errors that are my fault.

The Bottom is this code from a DarkBasicClassic "DBPro Style Matrix Tutorial"



Any thoughts?

[edit]NOTE: The Matrix Tutorial looks better - but its not right - I know from moving the light around and the shadows are't "orderly" - Very Visible in my island picture - I have 1 light - and there are shadows is strange spots. Tests with a spotlight were WEIRD too - Where the Spotlight was "ME" the Camera - and as I zoomed around - many strange things with lighting. Like Facing one direction - made everything black - and another ..all lit.

The reason I think the Matrix Tutorial is close is because - well - it works on a DBPRO MATRIX - But I'm pretty sure its a LOWER-LEFT = Coords (x,y)=(0,0) where my terrain its the Upper Left (x,y)=(0,0).

I tried playing with it - trying to to reverse the "order" in the math routine and the loop - and I didn't have any luck.


Thanx Again
[/edit]
[edit] Some Editing to make the post read easier plus:

I Do know the Whole - grab values from the memblock I do (using like a C STRUCT) works - and I even think I understand some of the math now! THANKX FRANK! I'm thinking I may need to combine FRANK'S Math - for Averaging and for "Normalizing" the End Results to within -1 and 1, but first do the ATANFULL trick to get the angles between verts and then make the NORMALS a 90degree from that - kinda like the FLAGPOLE analogy. This - once normalized - and stored back in the VERTEX NORMAL data - should in theory give me FLAT SHADING.

Now if I took all these "FLATSHADED" Normals - Put them in a data structure - (As My New Source of data to do math with) and AVERAGED all normals (on a given vertice) and saved those AVERAGED values back to the OBJECT's VERTEX NORMAL DATA where they should go - in THEORY - I'm thinking that should give me Gehroaud Shading (or whatever) that makes stuff seem less "Hard" at poly seams - and gives a softer look - (Less computer'ish).

Now this is a edit and I'm just thinking outload. I Welcome REsponses -



/edit]

Attachments

Login to view attachments
tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 18th Dec 2007 20:31
Hi,

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 );

Hope this helps.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 18th Dec 2007 21:06 Edited at: 18th Dec 2007 21:07
Thanx again - between you (tparkin) and Pharoseer - I think I should be close to a resolution - (BTW) Saw Your post in DBPro Forum TParkin - thanx - and I'm going to try using Dark Commands to try to consolidate and maybe even eliminate my own bugs - but the math you guys are suggesting seems so similiar - I MUST try it more and more until I get it -

I will admit - I'm curious why the ATANFULL looping method ALMOST works though. I guess maybe because it is finding the angles long hand versus a wrapped up equation?? [edit] and is close to being the same thing [/edit]

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 18th Dec 2007 21:35
Looks like the ATAN method (without spending too much time trying to figure out what it's doing) is a hack-method of trying to compute normals. The method I posted in the other thread is the "official" way of calculating a normal. Not only is it short and simple, it's also very computationally inexpensive. A cross product is just some multiplications and additions of vectors as opposed to any trig functions like TAN.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 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!

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 19th Dec 2007 04:23
well if your just looking to set the object normals there is a command that will set them for you.

also there is a directx way to do it through darkGDK. Anyways the command is.

dbSetObjectNormals( MyObj );

does that help?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 04:41
Hi David - Yes and No. It SHOULD help. I heard that function is buggy in mesh more than 1000 verts - that's why I didn't want to mess with it.

I'm actually grateful for everyone's help - but I'm glad Pharoseer showed me the "Hands On" Math - because I understand more generally - and then having TParkin - roll it up into 3dmaths code helped with getting used to working with DarkGDK 3dMaths(vector stuff) a bit...

But yeah - if dbSetObjectNormals just worked - I'd be free and clear I'll try it out for the heck of it - and see if I can't blow it up again - I did once before - but I didn't know the "hows" as well as I do now.

thanx for the post!

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 19th Dec 2007 04:43 Edited at: 19th Dec 2007 04:44
if that dont work I will post the darkbaisc code that access's it straight through directx.....works exactly like dbsetobjectnormals. except that it will work on anything.

you have to translate it into GDK of course.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 04:57
No Dice - I get a ton of these:



david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 19th Dec 2007 05:27
can you post your mesh for me

so I can have a crack at this.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 06:02 Edited at: 19th Dec 2007 06:38
Sure David. BTW - I just found this link:

http://www.idevgames.com/forum/archive/index.php/t-2401.html I just implemeted Ipetrich's example.

This looked like a good read also (I only scanned it but gets right to the meat of things) http://www.geocities.com/wronski12/3d_tutor/shading.html

Screenie: (This is the best I've been able to get so far ... proper "shadow looking" wise)

FullSize: http://www.jasonpetersage.com/img/NormalProgress.PNG



I hope a DBO is ok.

[edit] Some color -grass anyways Different Mesh resolution (more poly) than the attached DBO and its smoothed. I didn't smooth while doing tests above - the sharp points give clues
to what might be wrong



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

Attachments

Login to view attachments
Pharoseer
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: Right behind you
Posted: 19th Dec 2007 06:48
Hey Jason,

I glanced at the code snippet from the version using the math I showed you. The only thing I see is a result of an oversight on my part, not yours.

You have to normalize the vectors once you're done. Otherwise the lighting calculations are skewed drastically. Lighting assumes that the normals are 1 unit long, if the normals were say 2 units long, you'd get effectively twice as much lighting. At least that's the way I understand it.

I remember seeing a tutorial or example that had a sphere changing size. If you turned off normalization the lighting on the sphere changed based on its size. If you turned normalization back on, it was lit the same no matter what size it was. I wouldn't swear to it, but I've seen a couple of people mention that if you call dbSetNormalizationOn() it might normalize the vectors for you - even on your "hand-made" objects. I'll have to test that out myself.

That being said, your progress on this is amazing! I'll have to look at Ipetrich's example as well. I've been working on an idea for massive terrain that might benefit!

And I'd also like to apologize for throwing more math at you than code in my earlier explanations. I've been meaning to figure out how the 3DMaths in GDK work.

If you need any more help or would be interested in collaborating on this let me know.

-Frank
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 19th Dec 2007 06:54
how does this look to u.

Attachments

Login to view attachments
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 13:16 Edited at: 19th Dec 2007 13:48
@ Pharoseer - Thanks for checking it - out - No Problem - games for anything - no big deal - and I'm glad you gave me the match long hand - I understand it more that way - and then I appreciate the 3dMaths once I KNOW why I'm calling them Collaboration is a good thing

@David - It looks good - I see seams though - WAY better than mine was at first. You do seem to have the Geroud Shading working or close. I don't know if you just smoothed the landscape or what but it looks interesting.

Can you toss a sun light across it like I did? One of the main things I'm shooting for is all shadows (non bright poly - I know its not reallt casting shadows) on polys facing away from sun and not appearing random.

You might already have done the averaging.. and if that's why its so smooth - I understand why you have the seam - that part is a pain figuring out the other "adjacents" (Took awhile over here when making the verts raise and lower - especially for ALL places - the FAR right - far bottom right, the bottom ..etc.

Good Brain Teaser!

Gotta go to work soon guys - I Thank Both of you for really digging a bit here with me - definately all of you are going above and beyond I'm learning alot... I still don't know why cross products works - but I'm glad it does. I tried to think about doing it all with from scratch - using distances and atanfull... BAH

[edit]@David - Just so you know - I've looked at what I wrote - and I need feel I should emphasize that what you did looks really cool - and the more I thought about it - the more I realized you were at a disadvantage because I have a little "Poly" map to help me write the "code" - a reference sheet I made (Visually it helps me figure out stuff. [/edit]

Attachments

Login to view attachments
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 15:16
Here is the Source So Far - I know its not optimized at all - no classes etc... but its a "TEST" app - and has become the "Working Base" I'll eventually integrate into my Inron Infantry/DarkGDK OOP stuff -

See Attached - in the MemBlockMeshTest.Cpp - there is the source for the Keypresses - and I did a quick set of "comments" at the top to show what they are - (I think all of them) - Rememebr - this isn't a demo - its me Trying to learn this stuff - and crankning out code that does the job.

Attachments

Login to view attachments
Pharoseer
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: Right behind you
Posted: 20th Dec 2007 09:26
Hey Jason,

I haven't had the chance to look at your code yet, but if I can think of anything or spot anything that might help you get this working I'll let you know. Also, if you ever need help with math, let me know. I double-majored in math and computer science. I'm a bit rusty, but I kept my textbooks. I've been preparing for the intricacies of 3D programming for a LONG time.

Oh, and I could show you why the cross product works if you want. It's pretty simple, but it probably wouldn't help to know the WHY (unless you're like me).

-Frank
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Dec 2007 13:33 Edited at: 20th Dec 2007 16:12
Thanx - Frank

[edit]
Last Night I began "Tightening it Up" into a class - So I don't have all that MEmblock Nonsense as a structure! Also so I can literally have "Multiple" Terrains if I wanted to... Though Normalizing THOSE seams will be a trick if I even try to do that!

I have the beginning of a nice lib for tiing alot of stuff together - and terrain is a natural fit - Because I have stuff OOP's for Memblock, Objects, Images, and now....

I even starting REALLY looking at the LIT Frustrum Port - and Frankly - It's not as "hard" as it looks. I mean - It's a @#$%$@#% to Write and get correct - but you can see in the logic it does boil down to a list of "Coords" for each object/limb - that are like a bounding box. If ANY within the calc'd "Screen View Port Range" - Then Show else hide.

Now - Implementing is a CHORE - Lots of x1*x2 - y1-...gibberish.... ...Wait - I forgot - Frank can read that like a first language! He's good like that! I TRY... I really do - but sometimes - I just get the logic right - understand it enough to utilize it. And frankly - the Frustrum math - MATRIX math gets a little funky! After the terrain stuff - this 3d math (and a few web sites on the matters of 3d brain stuff) I'm getting a CLUE - ...just a clue though.

Like - Even LIT who wrote the port - Amazing Feat - and I were discussing this and I asked "How Does Multiplying a Projection Matrix and a screen Matrix give a plain? We just both agreed in the end we didn't know why but were glad it does....somehow

I really don't understand why moving my light around isn't making the shadows "move" accordingly.... I wonder if its GDK thing? [/edit]

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 03:34
Ok - To Conclude this thread - I found out a few things about lights recently with help from tParkin, some DBPro test code, and a bug fix in my code - but generally - I think I discovered the following:

1: Directional Light's Can't be Positioned - just Aimed. This Means that if it is going to be my "Sun" I need move my Terrain "under" this light - and point the light correctly -and move accordingly for a Time Of Day Lighting! Weird. This would mean all my 3d Stuff needs to have a variable Reference point.

2: SetLightToObjectPosition Never Worked For me - regardless of Light Setting (Point, Spot) at least with Light Zero.
Use dbPositionLight(LightID, x,y,z); <---It works.

This explains alot of issues. Though in the Code Snip Above - Where I was saying I move my light - I had a speed value where the ObjectID should have been - but ultimately, this didn't fix it because of the whole dbSetLightToObjectPosition thing.

Well - that concludes this thread for me - I'm pretty much better off thanx to all of you. I understand this Vertex and Lighting better now, meshes, and the meaning of life... well.. not that part

Thank You All

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 21st Dec 2007 03:38
You are wrong about the lights
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 03:46
I'll buy that. Can You Elaborate?

I'll gladly try a suggestion - and I'd be tickled pink if I can learn another thing about em!

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 21st Dec 2007 03:46 Edited at: 21st Dec 2007 04:20
You are correct that a directional light cannot be positioned, only the direction can be changed. You don't need to move your 3d objects, that will have no difference.

To emulate the sun as a directional light you just change the direction. For example, assuming positive X is East and negative X is West. The sun rises in the east and sets in the west so you would start the direction at -1, 0, 0 (pointing from the east) and end it at 1, 0, 0 (pointing from the west)

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 03:50
Phew - THANX - that is REALLY REALLY Good News The Help and My Tests allowed me to arrive at that - but your explaination has set me straight! (And happy'er)



Help
Quote: "
This command will set an existing light to that of a directional light. The direction is specified using directional values assuming that the origin of the light is 0,0,0.
"


tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 21st Dec 2007 03:58
The code above shows how to use some basic trig to calculate the direction of the sun at a given hour assuming east to west rotation. Right now it goes by hour block, so it's not smooth - but that's easy to fix once you get the idea.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 04:08 Edited at: 21st Dec 2007 04:08
That is awesome - Thanx - I didn't see that if it was there before - I was just sitting here trying to figure that out - thank You very Very much - this is too cool - its like you start hitting some advanced stuff - or trying to and all of a sudden I have all these power hitters helping me out - this ROCKS!

Thanx!

tparkin
17
Years of Service
User Offline
Joined: 28th Mar 2007
Location:
Posted: 21st Dec 2007 04:21
I updated the code in the previous post to make it smooth. The next step would be to make the sun dimmer at night and brighter during the afternoon by setting the color of the light based on the hour (or easier, based on the angle).
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 06:05
That is cool - Did you see the light Demo David W Gave me? That was pretty awesome too... the more I thought about it - he had this down like it was nothing!

Hey TParkin - I looked at that code and found you are missing the "#" where angle is used in the bottom of the main loop - and when I changed it and enabled the sphere - I could see the "Sun" go around the cube - was very cool.

This is a little off original topic - but - I was brainstorming about all this and was thinking about three main approaches (with over all goal being nice scenery and sky

1: Sky Box Database - (I have a bunch) - Currently I have Water Shader Textures to match each ( Or Default the shader to use sky texture for a generic water color reflecting sky look) some Have "Sun" as part of the Sky box... So I thought if I could move a sphere - (while the skybox was on screen) - and the camera to help get around - to the spot where the sun "appears" (scale of skybox etc. makes it a moving target until you nail your numbers down but...) Move the Sphere so its "right In" the Plain of the skybox where the sun is at and then somehow calc the Angle back to 0,0,0 coords - so I don't have 90 degress - I have that -1 thru 1 (like the normals) angle - so I could add these coords to the Skybox "Database" - so that a given skybox automatically can make the sun direction Correct.

2: Using Your Sun Rotation - A Sky Dome - and perhaps some VERTEX tricks - like per VERTEX lighting (coloring the vert to get a gradient down to the horizon) I figure It may be possible to make a SKy Dome actually seem to light like the sky (to a lesser degree...sky can be gorgeous) but I could try - so like you said about time of day sun brightness/color - I could make a sky dome do something similiar as well. Some Fancy algorythm to make the vertext change towards blues and eventually blacks and stuff in the evening etc.

3: Sky Boxes without Sun drawn in - and a ghosted plain for a sun - ghosted might be the trick - add some lens flare - and your time of day rotation logic to get things working like that - nice detailed sky, sun, and flare.

While I'm at it - I should probably consider the moon just the same!

Though moon phases might be a trick!

What ya think?

Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 21st Dec 2007 12:24
Didn't have time to read all of this so sorry if it has been resolved, but ADR posted the normal calcing code I use on the forums.



And then you can use set object smoothing if you want the normals to be more even. Of course you would not create and delete the 3 vectors for each poly. For some reason creating and deleting vectors is quite slow. I just create all the ones I will be needing at the top of my code and delete them at the very end.

Also about the Frustum port ... alot of that was added due to DBP being wicked slow at alot of stuff. You may be able to do away with alot of it fo the DGDK without much notice in speed.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 13:08
But Optimization is cool! Be sure you know I wasn't nit picking which I think I did to David W's Screen Shot originally - and I feel bad now...

He hasn't been too verbose since Sorry David! You did better than me!

LIT - The same optimizations I'd suspect would be just as advantageous in DarkGDK. I've studied it enough to know the code's magic matches our 10,000ft discussion - prior I just took your word for it.

I saw your "Hooks" for future oct-tree as well and I am curious about that as well.

@VanB - I was thinking along those lines to - that having "lod" tiles with the edges having same count as the "next higher" detail level would allow for seamless vertice welds.

I'm having some issues with VCExpress Now - Still - I Thought I resolved. I made one solution - with multiple projects - each a module of source - Foundation Classes - Game Classes (Oop wrapper) - The Test Terrain App, and Iron Infantry. Now - regardless of tons of hacking - Iron Infantry won't link - "Entry Point not defined" But all the other three work fine - and frankly it compiled and ran before I organized my code better. Maybe I should load up 2005 Pro or 2008 Express...hmm.... Dunno. There is only one DarkGDK(void) in it...so I'm perplexed...(I hate dumb stuff like that where you waste potentially hours getting nothing done really)

Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 22nd Dec 2007 02:14
Quote: "I saw your "Hooks" for future oct-tree as well and I am curious about that as well."


I thought I had removed all of that in the latest code 0_O You can probably just removed that for sure. Every type of tree I came up with ran slower than the culling alone in DBP, so I removed all of it. I tried my hand at binary (was the fastest), octrees (slowest), and quad trees (middle speed). All were just too slow and I am no expert at trees, so it may have just been my way of doing it. I have a couple of great examples of trees in c++ code somewhere. I can try and find them if you need them or you can google it. I had a version using the LUA plugin, but the overhead and complexity wasn't enough to warrent it's use with the very minimal speed increase. It is DBP's arrays that are wicked slow. Plus I wanted it to be DBP code only as much as possible.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Dec 2007 04:09
Makes Total sense - I snagged your code eons ago - and held onto it like the holy grail of FPS

I've read sorting algorythm stuff before and they all have strengths and weaknesses...and admittely - I was usually the weakness as many are a bit complex. Some of the ones I Understood - were pretty darn fast but the drawbacks were small - where some of the touted best needed to be carefully chosen for certain data sets etc. as their strength had a weakness - in that many - in one situation are lightning - and another - well - not so great - and unless carefully worked out - data + algorythm = fast - you can get a lot of code and ...well... not what you thought you would get.

There is a routine - for sequential numbers - I like that halves the array on simple > and < (Greater than and less than if reading this in text email forum readers) That each time it does this logic - it cuts the search in half. I'm thinking if worked out correctly - algorythms like this that are just mechanically faster than looping through a ton of iterations - (by halving each cycle or some other neat trick) might be the key for such a thing.

I'm not ready either to start getting that advanced though. I'm still trying to learn to much of the "techniques" for all this. So I'm trying to follow the KISS priniciplpe where possible.

The key to getting stuff working tight and manageable - is one little piece at a time... and nailing it...and building on it. I still need to learn to walk before I run! I'll leave the "Tree" stuff alone - though I believe in their principles - but I'm not sure how to apply that to a 3d grid where the camera can be looking anywhere. Kind of makes "think Ahead" algorythms a bit tricky.

Login to post a reply

Server time is: 2024-11-17 00:25:49
Your offset time is: 2024-11-17 00:25:49