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 Discussion / Greetings and a humble problem with Object Screen Y...

Author
Message
Zero G Scott
17
Years of Service
User Offline
Joined: 14th Dec 2007
Location: California, USA, Earth, Sol Sys
Posted: 27th May 2009 06:47
Greetings,

As a recent purchaser of DB Classic I've finally found a problem thats stumped me for a bit. Seeing as I could probably spend more time trying things I thought this would be a great way to introduce myself a bit and get a little feedback.

I've been hovering in the background for quite a while (over a year or so)reading the forums and enjoying the various aspects of DB as a beginners tool to programming. Then I finally got it and started to play around with things.

As a little background I'm interested in space games quite a bit and Evochron Legends creator inspired me to explore DB and see what I could play around with. So on that note I'll describe a little about what I've come accross and what I was thinking.

Since my logic and coding skills are a bit on the humble side I started to play around with taking 3D objects and moving them around with the commands to get a feel for things with the intention of eventually creating a simple scrolling shooter in 3D. For now though its simply an instrument for learning to code and becoming familiar with DB.

So on to the problem I've come accross...

I started with the intention of trying to figure out a method for limiting an object which is bound to the mouse to the screen in 3D space while having the camera tilted and a specific angle to a plain. I'm sorry if thats a poor description, it should make a little more sense when you run the code...

Anyway looking at the code...I decided I would make a 3d object, place it at 0,0,0 then position the camera. I would then run a test to find where exactly the 3d space positions are for the edge of the camera screen. So I end up checking the Object Screen X and Y of the object while incrimenting its position along the X and Y in 3d space until it reaches the known resolution boundries
of the screen resolution.

The problem...well I got the X numbers just fine but when I try the exact same method for the Object Screen Y it freezes up and I'm a little confused as to why since it appears to be the same. So I thought I would come here and post the code to see if someone sees something I don't in my logic.

Now I'm pretty sure there is an easyer way to gather this data using some kind of math which eludes me for the time being so feel free to suggest another method. Just be gental please, I know my code might be a little unkempt and dis-organized and I'm still curious why its freezing and how to get it working even if there are better ways.

Looking forward to the grilling.

Heres the code (I hope)...





P.S. Bare with me as this is quite litterally my first post here and I try and figure out the buttons and features.
Zero G Scott
17
Years of Service
User Offline
Joined: 14th Dec 2007
Location: California, USA, Earth, Sol Sys
Posted: 27th May 2009 18:26 Edited at: 27th May 2009 19:36
Well, a funny thing happened on the way to the forum...

So since this was my first post theres that delay while the mods approve my post, and during that time I looked back over what I said and noticed I forgot to mention to rem out a couple lines to get the freezing problems. So while playing the code I decided to trim it down even more and try and isolate it down to just illistrate the problem. So while doing that I realized I wasn't displaying the x,y,z position of the object as it was moving around so I decided to add those, and while adding those I noticed that the Y axis wasn't moving AT ALL. Which pretty much told me what the problem was. I was using the wrong axis commands in the code. /bonkself

So I got to thinking why I did that and I realized that in this example Y is actually up and I'm used to Z being up since I've used a lot of 3D programs that always have Z up...

Soooo, yea. Troubleshooting for the win! This was still good to get my existance out to you guys here a bit and let you know your not totally alone.

So basically in this example I was trying to get a method of finding the screen edges in 3D space using a specific camera angle, with the hopes that I could then use the method again when I decided to change the camera angle. I could then use those limits in 3D space to move a 3D object around while being attached to the mouse.

Heres my fixed version with the correct numbers being displayed at the bottom of the screen when run. Yea my mouse to object code is a little flaky but its by design.



The funny thing was in the code above I had placed the correct commands in the Z axis of the DO looping code even though I was still refering to it as the Y, so the clues were there all along.

At any rate, Hi and thanks for listening. I'll see you around!
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 28th May 2009 02:32
@Zero G Scott
Greetings back!

Just curious, did you email to my old DBC to Blender direct x script site?

Enjoy your day.
Zero G Scott
17
Years of Service
User Offline
Joined: 14th Dec 2007
Location: California, USA, Earth, Sol Sys
Posted: 28th May 2009 02:52
Yea that was me, I'm trying to find a good way to get smoothing groups into DBC from blender and just came accross that site today. Figured I would ask about it. I do have one method but it involves using milkshape 3d as well and I don't know if animations will translate accross as well yet. Eventually I'll explore importing animations. Its all depending on my understanding as I try things in DB though so I'm trying to just go from where I am and not try to jump ahead too much.

I also notices a jump in verticies when exporting from obj from blender to milkshape 3d then .x to DBC. I don't know if it has any bearing on performance but I've been told it does. Was curious about that as well though. While I have your attention I may as well ask about that too.

Thanks for the hello Latch, I've liked reading your posts, they're often interesting and informative.
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 28th May 2009 04:42
Hello Zero, you've kept very quiet.

More vertices mean more polygons means more maths so yes it slows things down.

Quote: "`Turn the positive y value negative so the object goes up and down correctly
VAR_TrueYValue#=VAR_CurvedYValue#*3
VAR_CurvedYValue#=VAR_CurvedYValue#-VAR_TrueYValue#"

Multiplying by three and subtracting the result would leave you with the negative *2. Did you mean to do that?
There is a simpler way to invert (is that the word) a number: n*-1, or if you really did want to n*-2.
Or 0-n or 0-n*2

There is an eight letter word. You can insert a letter into it or remove a letter from it without changing its meaning. Answer
Zero G Scott
17
Years of Service
User Offline
Joined: 14th Dec 2007
Location: California, USA, Earth, Sol Sys
Posted: 28th May 2009 05:08
@OBese87

Hello, that was my embaressingly clunky way of turn the value negative (giving the mental state I was in), and at the time there was some reason why I multiplied by 3 which for the life of me I can't recall. I did take out a bit of code there that wasn't working so maybe it was leftover from that. Anyway, thank you for the tips, that will definatly come in handy! I seam to have a better time figuring out logical statements rather then using math. Hope we can chance that!

I bought DBC in January so I haven't really had much to talk about till then, and since then I didn't want to be accused of not coding for myself first before posting so I haven't had anything dire enough happen that compelled me to post until now. Which if I had followed with this example I probably still wouldn't have posted, HAH. I'm thinking too much I think.

Thanks again for the response!
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 28th May 2009 11:08
Quote: "I also notices a jump in verticies when exporting from obj from blender to milkshape 3d then .x to DBC. I don't know if it has any bearing on performance but I've been told it does. Was curious about that as well though. While I have your attention I may as well ask about that too"


Quote: "More vertices mean more polygons means more maths so yes it slows things down."


This is true but the presence of more vertices doesn't always mean more polygons. But a general rule of thumb - more anything means more work the computer has to do. But there are even exceptions to that like writing some code straight out 10 times in a row as opposed to writing a function and looping through it ten times. And in terms of polygons, 4 planes totalling 8 polygons will have slower performance than 1 cube with 12 polygons. Both situations have to do with the processor having to jump to and/or keep track of different memory areas to get information instead of reading all the info from the same place in sequence. So yes, polygon count effects performance, but there are other factors influencing the situation.

Anyway, vertices have other influences than the creation of polygons. You could make a cube with 8 vertices, 24 vertices, even 36 vertices if you wanted, but if you were using triangles for the faces then you'd still have 12 faces/polygons. More vertices than what seems necessary are often present to allow each face to be made up of it's own set of points. This can help in UV texturing where the number of UV coordinates may match the number of vertices and allow the rotatation or individual manipulation of the texture on each face. If the vertices/UVs are shared (in the case of the 8 vert cube for example) changing 1 face may change another in ways that you don't want. Also, if you have multiple vertices in the same location, you can control lighting and coloring more subtly than what can be done with a single vertex at a location. You could have multiple vertex normals to help reflect light on the object in interesting ways.

So between 3d modeling programs and file formats, the number of verts may change depending on how that program builds faces, uv texture coordinates, and calculates the normals (influence of lighting on the object).

Enjoy your day.
Zero G Scott
17
Years of Service
User Offline
Joined: 14th Dec 2007
Location: California, USA, Earth, Sol Sys
Posted: 28th May 2009 18:46
In the instances I'm refering to the poly count stayed the same but the vertex count went up dramatically. I do recall reading a possable cause being the storing of UV information which verifies to me what Latch said. Good information to understand and look out for while using different 3D software.

What I immediatly thought of was what if I wanted to move verticies around in memblocks, would it add more to do as far as points to check or is the information layed out well enough in the file that it would just be a matter of knowing where the points that are relivant to changing the geometry are layed out in the file format (in this case how points are stored in the X format). I'm rather ignorant as to the workings of memblocks though and I know theres lot about them posted in the forums so I'm not really asking for a walk through of those. Ultimatly what I wonder is if the specific 3D program used to create the model would add to how much work needed because of how it stores verticies.

Good information Latch, thanks for that.
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 9th Jun 2009 12:28
Quote: " Ultimatly what I wonder is if the specific 3D program used to create the model would add to how much work needed because of how it stores verticies."

That depends on so many things. Was the 3d program written by a good programmer? Has the 3d program been field tested? Does it use plugins or 3rd party software to do the conversions between file formats? Is it a competitor to another format and it's in it's own best interest to have a scaled down or semi functional version of a competing export? Are the exports written by regular users for their own purposes?

Then there are specifics like the type of file it is. A motion capture file, for instance, may only contain position and rotation values as well as the start and end points of the pivots, joints, or bones. Then there are procedural generation of primatives and shapes. Does the file format only contain procedural information to generate the specific shape internally? A conversion program may take that procedural information and translate very differently from the internal calculations of the mother 3d app. So there's a lot of factors.

In general, exporters are written so the exported data is as close to the information that is contained in the 3d app as possible. You're subject to what the file format allows and what will be read by the target software. You could have a great direct x skeleton exporter, but the animation data will be useless to DBC.

I guess in answer to your question, yes, the specific 3d program could add to or lessen the amount of work you'd have to apply to sort out model information in memblocks; though memblocks are consistant in their layout and inherit the vertex order that the original loaded model supplied.

Enjoy your day.

Login to post a reply

Server time is: 2025-05-16 08:50:28
Your offset time is: 2025-05-16 08:50:28