how to divide a triangle into smaller triangles

deepthought · November 4, 2010, 12:23pm

i’m using lwjgl for a game, and i’m gonna put all the textures into one big giant textures so i can render it all with 1 vertex array. the problem, though, is that i can’t use GL_repeat. So, how do i divide a triangle into smaller triangles that’ll fit. then i’ve got to do the same thing with the texcoords.

lhkbob · November 4, 2010, 1:03pm

Why can’t you use GL_REPEAT? Is the only reason you need to split triangles so you can get the effect of a repeated texture?

princec · November 4, 2010, 1:06pm

And why do you want to render it all with one vertex array?

Cas

bleb · November 4, 2010, 1:25pm

If I was in your shoes, I’d want to know for sure that the benefits of fewer texture binds outweighed the work of splitting up your geometry. I’d be very surprised if the benefit was significant enough to merit the programming time needed.

princec · November 4, 2010, 1:29pm

Texture binding isn’t the great expense it once was either… GL drivers these days are super pipelined command queues. You set up tons of little batches of stuff asychronously on the CPU, and the GPU starts slurping the commands off the queue before you’ve even finished. If you’re lucky you can keep them both busy but anything made in the last 3-4 years you’ll have to try pretty hard with an indie effort to max either of them out…

Cas

deepthought · November 4, 2010, 10:55pm

uh… hahaha you haven’t seen the computers at my high school. also, i figure itl, help with lighting when i get into shaders. i’m gonna create a type of light that uses part of a texture as the light color. quite useful for making projections. and, i figure that rendering with 1 vertex array is simpler for me than using a separate vertex array for each texture.

Riven · November 5, 2010, 12:47am

It’s simply not simpler.

Stop wasting your time, and do it the easy way, make it work first.

Premature optimization is the square root of all evil.

ewjordan · November 5, 2010, 4:33pm

Riven:

Premature optimization is the (1.0f / fastInverseSqrt()) of all evil.


public static double fastInverseSqrt(double x){
    double xhalf = 0.5 * x; 
    long i = Double.doubleToRawLongBits(x);
    i = 0x5FE6EB50C7B537AAL - (i>>1); 
    x = Double.longBitsToDouble(i);
    x = x * (1.5 - xhalf*x*x); 
    return x; 
}

Fixed that up for you, should run a lot faster now.

At least that’s what this awesome article about software rendering in C from the late 90s told me, and if it works in C, it must work even better in Java, since Java’s so slow! I herd that the guy that made Doom invented it.