Game Development

1:46 AM

@Noctrine hi! long time no see :D

@Gajet Yeah, been ridiculously busy with normal work. This is the first day that I've been able to get back into working on my game projects in awhile actually.

it's exciting, except for the massive backlog.

Gajet

@Noctrine now that I'm thinking I can't remember what was the game you were working on!

Noctrine

Virtual Pet game

Gajet

did you ever mention what it is?

any screenshots? videos? anything?

Noctrine

Not yet, soon though.

Gajet

1:54 AM

I'm not sure what is steam downloading :|

it's using all my bandwidth (100KBps) for the last 30 minutes.

and it doesn't report any downloads

Pureferret

2:16 AM

@Gajet man steam be crazy

Gajet

@Pureferret turned out it was my brothers PC,

downloading through my computer :|

right now I'm connected to router via wireless and I'm sharing my connected over the lan

JamesGuthrie

11:34 AM

Hi there, is anyone around?

Martin Sojka

12:29 PM

... on a sunny Sunday afternoon? Nah.

Jeff

3:48 PM

@melak47 I found the prequel dl.dropbox.com/u/679615/mayro.html

Meow

10:21 PM

Is using vertex buffers faster than sending geometry to the video card every frame with low-poly meshes (mainly 12-triangle blocks)?

melak47

send them how?

Meow

i.e glBegin(GL_TRIANGLES); / glEnd();

melak47

@Meow 12 triangles? is it a cube?

Meow

yup

melak47

I don't know about openGL, but in D3D you can make drawcalls without a vertex buffer bound, and it will generate vertices (with no attributes except an ID). you can then send those into a geometry shader and generate cubes from them

are the cubes all axis aligned, or can they have arbitrary orientation?

Meow

10:32 PM

Actually i'm developing a 3D brush-based editor, so it allows any kind of convex brush

melak47

deformed cubical brushes, or something else?

Meow

like Valve's Hammer

melak47

i.e. you let the user pull the vertices around as they like, or can they edit the brush further

Meow

any kind of convex polyhedra

melak47

never used it

Meow

10:34 PM

yup

melak47

hmm. yeah I suppose updating a vertex buffer all the time when the user is editing it might be a hassle

Meow

so they are being modified every once in a while, and there's usually tons of brushes in a single level

i guess, although sending all those brushes every single frame is overkill, too

melak47

I suppose you could send the vertices only when the user is editing a brush

once done, put them in a buffer

or even at regular intervals

Meow

I thought about doing that

although someone told me that there's some overhead from switching between lots of buffers

melak47

yeah

Meow

10:37 PM

besides, every single face of a brush can have its own material and textures in the worst case

melak47

well I wouldn't know about openGL anyway, but lots of API calls, especially binding of stuff, slow things down

Meow

yup

melak47

hmm. you could batch up all faces of geometry the user is not editing into buffers of same material

but then worst case scenario is recreating the entire buffers when adding a new one to them

Meow

yeah, that's the first thing i'm gonna do: sort by material

also, I need to apply transformation matrices to the buffers while a brush is being translated/rotated for preview purposes

melak47

openGL probably has geometry shader stream out as well, so maybe you could use the graphics pipeline to push changes in the geometry to the buffers

hmm

melak47

10:57 PM

if you keep the brush in vertex buffer from the beginning

you could identify selected vertices with a bitmask by ID

and supply movement information via shader variables

so if the user has selected the entire side of the brush, set the bitmask/flag, and how much and where it moved, let the vertex shader apply it, and have the geometry shader stream the modified position out into another vertex buffer. then swap the buffers.

a double buffered vertex buffer I suppose.

Meow

Actually i'm using irrlicht as a rendering engine

so I want to apply the transformation matrix to the "driver" before drawing the vertex buffer

melak47

is that too low level then?

driver?

Meow

so there's no need to update the buffers themselves

melak47

I'm not talking about the rotation

Meow

driver is the main rendering object, it's where the draw functions are located

melak47

11:02 PM

I was thinking for the user moving vertices of the brush

Meow

you set the world and view matrices there

melak47

you don't necessarily have to do the updates on the CPU then push them to the GPU

Meow

I guess

melak47

I've seen someone apply that to painting/sculpting style terrain editor

made the whole thing much more responsive

modify the data nearly in place on the GPU, with no bulky updates from the CPU slowing things down

Meow

although I have to transform those brushes on the CPU first, because 2D Views (using GDI drawing) have to be updated too

melak47

11:07 PM

2D views?

of the brushes?

Meow

i.e orthographic views

melak47

why not do them with openGL / irrlicht as well?

Meow

good point

I don't exactly know why I'm doing those views with GDI, it's just the industry standard

melak47

ew

Meow

LOL

melak47

11:10 PM

the concept might be overkill in your situation - if you limit it to only the object being edited, pushing those few vertices shouldn't be an issue

but just set an orthographic projection matrix (i.e. identity matrix, or maybe rotation :p) and you have your 2D views

Meow

My idea is: make a vertex buffer for every brush, then every time the user is dragging a brush (for scaling, translation, etc) draw the buffers with a transformed world matrix, after the transformation is complete (i.e user done dragging), send the new vertex data to the graphics card

melak47

why not just keep using translation matrices?

to cut down on API calls so you don't have to set them when drawing each brush?

Meow

because I calculate the UV coordinates after the transformation has been completed

melak47

why do the UVs change when you move or rotate the brush

Meow

because the faces may be world-aligned

melak47

11:21 PM

...?

Gajet

@melak47 funny thing, still your code generate different values compared to mine :|

melak47

@Gajet are either correct? :/

Meow

i.e, you have 4 walls with a brick texture, you want to translate a single wall upwards for some reason, and you want the room to still look seamless

Gajet

@melak47 both values seems to be correct both your output is more precise!

Meow

also, updating UVs is very important in scaling and rotations

melak47

11:23 PM

@Gajet all values I checked seemed accurate for 15 of 16 digits

Gajet

213 123 546 879 231
(0.383176,1.76459) : (7.95808e-013,0)
(0.383176,-1.76459) : (7.95808e-013,0)
(-0.32716,0) : (6.82121e-013,0)
(-1.01666,0) : (6.82121e-013,0)

(0.383176,1.76459) : (1478.52,-1701.18)
(0.383176,-1.76459) : (1478.52,1701.18)
(-0.32716,0) : (2.42871,0)
(-1.01666,0) : (226.481,0)

melak47

@Meow huh? I don't follow at all. why would the object moving mean it's UVs have to change. that would mean your object would "scroll" through your texture when it moves

Gajet

@melak47 you can see, the top results are yours and they seems to be equal to mine.

Meow

@melak47 exactly

Gajet

but yours is more accurate :|

melak47

11:25 PM

@Meow ok, that confuses me :p but you could just calculate the UV on the fly with position as an offset

in the shaders I mean

Gajet

@Meow I've only seen a cartoon with that kinda idea once, and I don't remember it's name right now. but it was kinda cool :D

melak47

if your UVs correlate to world space coordinates, treat them as such and translate them by the world matrix

Meow

@Gajet wat?

Gajet

I'm talking about UV changing based on world position.

melak47

@Gajet I'm a little lost here...the solutions seem to be exactly the same, how do they produce different results when inserted into the equation?

Gajet

11:28 PM

if I remember correctly, the main character in that cartoon was a man with yellow shirt.

there was big black dots on his shirt which always had same world position. it was like dots move on his shirt while he moved in the world. kinda cool :D

@melak47
123 564 134 45313 5312
melak
(2.25413319793779,5.99602776081763) : (0.00000000000000,0.00000000000000)
(2.25413319793779,-5.99602776081763) : (0.00000000000000,0.00000000000000)
(-0.11725015577545,0.00000000000000) : (0.00000000001819,0.00000000000000)
(-8.97638209375867,0.00000000000000) : (-0.00000000005821,0.00000000000000)
Gajet
(2.25413340633378,5.99602773700185) : (27123.10052482916900,-203618.40018272254000)
(2.25413340633378,-5.99602773700185) : (27123.10052482916900,203618.40018272254000)

melak47

ah, ok

ok...

Gajet

as I said the answeres are pretty much same thing, they differ only a little bit

melak47

when you calculate your output

you multiply by A, B, C, etc

but you don't take into account that you divided all the other ones by A already

Gajet

both outputs are calculated exactly the same

good point!

melak47

so multiply an A into the other terms and see if that changes the result

Gajet

11:33 PM

but still your answer is more accurate!

123 12312 423423 12312 43243
melak
(-0.01306338573603,0.31943261638391) : (-0.00000005666516,-0.00000000057253)
(-0.01306338573603,-0.31943261638391) : (-0.00000005666516,0.00000000057253)
(-50.03571710206884,30.59695536119716) : (0.00000030023511,0.00000009231735)
(-50.03571710206884,-30.59695536119716) : (0.00000030023511,-0.00000009231735)
Gajet
(-0.01306115103632,-0.31942586401401) : (0.01478672504015,-0.00504657140297)
(-0.01306574555790,0.31942590671703) : (0.01478672504004,-0.00504657142180)

melak47

the difference seems to start after about 5 digits

maybe you do some float literal calculations somehwere that only get converted to double's afterwards?

I pretty much wrapped every literal with complex<double> (...)

Gajet

now my results are more accurate :D

1561 5345 32154 5431 5345
melak
(-0.07310504126805,0.40781281370413) : (0.00000000015370,0.00000000002910)
(-0.07310504126805,-0.40781281370413) : (0.00000000015461,0.00000000002592)
(-1.63893852055129,-4.15467214303069) : (0.00000000018554,-0.00000000013461)
(-1.63893852055129,4.15467214303069) : (0.00000000018372,0.00000000013461)
Gajet
(-0.07310504126805,0.40781281370413) : (0.00000000000013,0.00000000000003)
(-0.07310504126806,-0.40781281370413) : (0.00000000000013,0.00000000000002)
(-1.63893852055129,-4.15467214303069) : (0.00000000000011,-0.00000000000009)

melak47

what did you change

Gajet

I had some float literals as you suggested

like 1.f/3.f

just removes some f from my code.

melak47

lol.

hmm are those all digits?

because now the solutions seem exactly the same :p

so how do they produce different results :p

Gajet

11:38 PM

because you didn't devide everything by a.

I've added
b/= a;
c /= a;
d /= a;
e /= a;
a /= a;
to your code and now they both generate same results.

melak47

but the solutions look the same

how can the same solution produce a different result when inserted in the equation

Gajet

float are not accurate, neither are doubles.

which means you can get off based on how large your numbers are.

keeping numbers near 1 seems to be the best practice available.

melak47

??? what I mean is on the left our numbers were the same, so how can they produce different results on the right, when you apply the same operations

Gajet

though it seems we still are producing results a little bit different :

2356 867 3287 548 3786
melak
(0.45188680205009,-0.97968476882916) : (-0.00000000000000,-0.00000000000000)
(0.45188680205009,0.97968476882916) : (-0.00000000000000,0.00000000000000)
(-0.63588510425722,-0.98803838047912) : (-0.00000000000000,0.00000000000000)
(-0.63588510425722,0.98803838047912) : (-0.00000000000000,-0.00000000000000)
Gajet
(0.45188680205009,0.97968476882916) : (-0.00000000000000,0.00000000000000)
(0.45188680205009,-0.97968476882916) : (-0.00000000000000,-0.00000000000000)

doubles are more accurate than 14 digist

melak47

where's the difference

I don't spot anything in those

Gajet

11:43 PM

2356 867 3287 548 3786
melak
(0.45188680205009280000,-0.97968476882916034000) : (-0.00000000000000044409,-0.00000000000000049960)
(0.45188680205009280000,0.97968476882916034000) : (-0.00000000000000044409,0.00000000000000049960)
(-0.63588510425722355000,-0.98803838047911974000) : (-0.00000000000000066613,0.00000000000000038858)
(-0.63588510425722355000,0.98803838047911974000) : (-0.00000000000000066613,-0.00000000000000038858)
Gajet
(0.45188680205009280000,0.97968476882916034000) : (-0.00000000000000044409,0.00000000000000049960)

@melak47 check the sign of differences to zero!

BBL

melak47

@Gajet: the are just in different order

melak47

11:55 PM

@Gajet, double gives you about 15 digits of accuracy. our solutions are different after the 16th :)

Transcript for