disappearing imported texture

y offs et · Post by **y offs et** » Sun Oct 18, 2009 6:11 pm

Why, when I use "R" to raise camera(player), does the crate disappear? imported texture - yes / any other kind of texture - no !?

diki · Post by **diki** » Sun Oct 18, 2009 7:01 pm

i think it's because you disabled the ZBuffer for the grapTest material. if i enable it, the crate stays.

y offs et · Post by **y offs et** » Sun Oct 18, 2009 8:08 pm

You are correct. Thank you.

I've re-coded jph's openGL work to y-vertical z-advance/retreat, just because I can. So that didn't register in my head.
However, that doesn't answer the question of why the generated textures are not affected in this situation. At least, I think it's a valid question.

diki · Post by **diki** » Sun Oct 18, 2009 8:37 pm

hm, when i set the grapTest-material to use a generated texture, the crate still disappears. maybe what you did was to select a different material instead of assigning a different texture to grapTest?

by the way, is this in any way related to baseball? it looks a bit like a pitching hill :)

y offs et · Post by **y offs et** » Sun Oct 18, 2009 10:34 pm

Yeah, I meant material. So why not with generated texture material?

I'm trying to invent a better gravity formula so we can make 3D terrains. That's just a test hump.

Pretty basic physics with few options. I read a thread on PAPPE physics engine, which looked promising. No progress though.

diki · Post by **diki** » Mon Oct 19, 2009 11:26 am

y offs et wrote:Yeah, I meant material. So why not with generated texture material?

i think the ZBuffer property is the key: on the material that uses the imported texture it is set to off, while the material using the generated texture has it set to on. the texture itself has no influence on the ZBuffer setting of the material.

jph_wacheski · Post by **jph_wacheski** » Mon Oct 19, 2009 3:04 pm

Yup, it sounds to me like just a zbuffer issue you are seeing,. loaded or generated, should not make a difference once the texture is in memory.

Also try setting RenderOrder to DephSorted for the target and the projectile. Works as well,. however I hav enot tested that much,. .

I am just curious, why do you like y-up better?

edit; just noticed that if collision is set to 'stop' the projectile will auto bounce,. but ONLY if the hit-ER is a higher collision cattagory than the hit-IE (your example Vs my old fps example) is this a bug Ville? it does make building things confusing,. I would perfere it worked predictably regardless of order and there was a separeate setting i.e. collisioin, stop, bounce

y offs et · Post by **y offs et** » Mon Oct 19, 2009 3:38 pm

I am just curious, why do you like y-up better?

I understand that you have learned 3D graphics from an openGL perspective, but.., pre-openGL the world revolved around DirectX, and I'm forever being confused dealing with two different viewpoints. By the way, I've turned that example 180 degrees now so that x is negative going left and z is negative moving forward. That is the world pre openGL, and it works for my history.

Not quite sure about your collision order re-arrangement finding yet, but... somehow I managed to stop the creep of the targeting sight.

Post by **Kjell** » Mon Oct 19, 2009 5:36 pm

Hi guys,

Didn't both OpenGL and Direct3D spawn into existence in 1992? Aside from that, wasn't Glide the dominant API in the early-days of 3D?

Anyway, OpenGL has the same default view direction as Direct3D ( X:Horizontal, Y:Vertical, Z:Depth ) .. so it primarily depends on how you'd like to face your Models in ZGE by default. When this is face-on, use Y as up-axis .. when this is top-down, use Z.

K

y offs et · Post by **y offs et** » Mon Oct 19, 2009 5:47 pm

Perhaps you have the spawn date correct, but as usual, the MS backed system raced ahead and captured the attention of most of the known graphics world, while openGL limped along.

It kinda mirrors the Cobol/Pascal hare and turtle race that began in the '80's.

Now most are equal, but the first off the line still holds the lions share.

y offs et · Post by **y offs et** » Mon Nov 02, 2009 6:33 am

I am just curious, why do you like y-up better?

I now know why you did it the way you did. That's the only way the steering controller works properly.

jph_wacheski · Post by **jph_wacheski** » Mon Nov 02, 2009 1:48 pm

Ah yes, I suppose that is another good reason. Sorry, I didn't recall about that,. I just went with the sdandared ZGE camera I guess. You should add it to the documentation! "Standard Behaviors are setup for the x-y plain" or some such,. . Note; if you use the expression behavior you CAN write in Z direction stuff as well, so the component can function in 3d too.

y offs et · Post by **y offs et** » Mon Nov 02, 2009 3:38 pm

Know of any example of using the expression? Vectors are handy but I haven't run across their use anywhere.

Edit - never mind - in Triple E.