Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›22 »

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I have an OpenGL question about vertex buffer objects. All the tutorials are dealing with a single buffer. They may be pulling vertices, normals, and other components from different buffers, but they're using them together. What I'm thinking instead is multiple buffers of vertices, normals, etc.

Right now I am trying to draw something from multiple buffers of triangle strips, with matching buffers of normals. When I draw it using vertex arrays, it does render correctly. I suspect I am screwing something up in how I go through the code. I don't have access to the exact code right now, but I can review my thought process here. If it seems correct then I can post the code tonight.

I'm writing in C, or rather procedural C++, if that means anything to you.

code:

GLFloat** vertices = // allocate and assign multiple GLFloat buffers of vertices
GLFloat** normals = // allocate and assigned multiple GLFloat buffers of normals

GLuint* vert_IDs = // store vertex vbo ID's
GLuint* norm_IDs = // store norm vbo ID's

for(int i = 0; i < number_of_buffers; i++) {
   // vertices
   glGenBuffer(1, vert_IDs[i]);
   glBindBuffer(GL_ARRAY_BUFFER_ARB, vert_IDs[i]);
   glBufferData(GL_ARRAY_BUFFER_ARB, sizeof(GLFloat) * 3 * vertex_count, vertices[i], GL_STATIC_DRAW_ARB);

   // normals
   glGenBuffer(1, norm_IDs[i]);
   glBindBuffer(GL_ARRAY_BUFFER_ARB, norm_IDs[i]);
   glBufferData(GL_ARRAY_BUFFER_ARB, sizeof(GLFloat) * 3 * vertex_count, normals[i], GL_STATIC_DRAW_ARB);
}


....
// Display code
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_NORMAL_ARRAY);	

for(int i = 0; i < number_of_buffers; i++) {
  glBindBufferARB(GL_ARRAY_BUFFER_ARB, vert_IDs[i]);
  glVertexPointer(3, GL_FLOAT, 0, 0);

  glBindBufferARB(GL_ARRAY_BUFFER_ARB, norm_IDs[i]);
  glNormalPointer(GL_FLOAT, 0, 0);

  glDrawArrays(GL_TRIANGLE_STRIP, 0, vertex_count);
}

glDisableClientState( GL_VERTEX_ARRAY );
glDisableClientState( GL_NORMAL_ARRAY );

Something like that. I get deterministic garbage, like maybe it's drawing normals as vertices or something. The same code refactored to do vertex arrays--eliminating the vbo bindings and such--renders correctly.

Side note: I originally had the buffers interleaved, but tried to factor that out in case it was causing trouble. Again, that worked with vertex arrays, but not the vbos.

I assume I'm doing something bad with the OpenGL state machine. Say, maybe I need to unbind someplace either while loading or rendering, but I wouldn't know.

# ¿ Apr 16, 2009 17:19

Adbot: ADBOT LOVES YOU

# ¿ May 5, 2024 11:09

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

OneEightHundred posted:

FYI though, you should consider a few optimizations:
- Keep all data in the same buffer if at all possible. Changing buffers is expensive, using a different location/stride in the same buffer is cheap.
- Use an index buffer and draw using glDrawRangeElements with GL_TRIANGLES as the mode

I hope you're not doing exactly this though:
code:
glGenBuffer(1, vert_IDs[i]);
... glGenBuffers takes a pointer, so it should be vert_IDs + i

MD3 would be fine for that then.

I think I was doing &(vert_IDs[i]). I just took an existing tutorial and started trying to manipulate it and ran into similar glitches so it seems that I screw it up from the point I specify the vertices. I'm trying to use triangle strips. Is there any fine print about using triangle strips with vbo's that one doesn't necessarily encounter with vertex arrays?

I originally was interleaved but unwound it all while trying to sort out why I was getting garbage. I thought it might have been rendering some of my normals as vertices in particular.

# ¿ Apr 17, 2009 19:41

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

The problem I was having had something to do with the buffer lengths I was specifying to the draw routines, so I got past that. The next thing I wanted to try was a pixel/fragment shader. Is Nvidia's Cg toolkit the accepted standard for developing shaders with OpenGL?

# ¿ Apr 20, 2009 14:00

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I was casually perusing the open-source game engines, looking for something that can take care of a lot of the nitty gritty so I can spend a lot of time on game logic. I was looking for a 3d engine, but for which I could develop something that renders most of the world in basically tiles; the world representation might be mostly 2d, but it would be a 3d environment. Think something like an adventure/action RPG. I was hoping there was something out there to take care of manipulating models for the most part and getting all the crap drawn with me kind of just pointing and grunting. Performance-wise, I hoped it would have an easy way to break everything up while allow seamlessly crossing a large number of tiles. I can program in C++, C, Python, and Java without any problem; I just as well assume it would be in C++.

I was looking at Irrlicht, since it seems to provide decent enough drawing facilities and adding sound and such at first glance doesn't seem like the end of the world. Is there something perhaps more suitable?

# ¿ Aug 18, 2010 06:39

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Nalin posted:

What is this "nitty gritty" that you don't want to spend time on? Irrlicht is mainly just a graphics engine with some support for additional things like input handling. It is probably the least complete package for game making that I can think of off hand.

I don't want to worry too much about collision detection, or least at the point of determining if surfaces within the scene truly collided, rather than doing some of the initial culling. I'd also like something that can load models and perform various actions associated with the model without having to have a lot of micromanagerial code attached to it.

quote:

Irrlicht is really easy to use, though, so you might enjoy it. Models can be loaded and added to the scene with only a couple lines of code, and you can easily draw 2D images. It also includes a bunch of tutorials that show just how easy to use it is.

That's what seemed good about it.

quote:

As for 2D tiles in a 3D environment, do you mean you want your tiles to actually be a mesh in your scene that you can manipulate? Irrlicht provides some 2D drawing functions so you can easily draw your 2D level then draw your 3D scene on top of it. But, if you want that 2D level to be a part of that 3D scene, it starts becoming difficult. You would be required to create your own custom scene node to draw your tiles. It also doesn't have any easy way to "break everything up while allow seamlessly crossing a large number of tiles." That would be your responsibility to do if you used Irrlicht.

I imagined the game having a mostly angled top-down view, with most of the world drawn up in a grid of tiles. There could be hills and ramps though, and special objects, but I figured the bulk of it would be tiles. Creating the world then would be a matter of making an editor to paint all these tiles.

I figured it would be pretty easy to cull the game world down to what's in the immediate vicinity of the view. I have done that before so that doesn't bother me too much. I suppose architecturally I could split the world up into various groups of scene nodes and be able to turn off these larger groups as I move around. Then each would have the various surfaces all plopped together within the group. Could Irrlicht then take care of the matter of getting it all in place, looking pretty? Could it then help me if I had something running around bopping stuff there?

# ¿ Aug 20, 2010 04:29

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I'm having decent enough fun with Irrlicht so far. As brought up earlier, I'm trying to create my own scene node type for represent world data in the tiled representation I want. It will probably be awhile before I get far with it just out of time, but I wanted to ask about some more general concepts here.

Generally what kind of detail do people leave to individual nodes in a scene graph? I think this is a general question since scene graphs are common enough. Is it common to, say, have an entire game level in one scene graph node? What about models and objects? Generally how are they generally organized in a scene graph?

I also have an issue with texturing. Image I have a grid of 2x2 squares that have the same texture across them in a way that the surface appears continuous. Now let's say I push down the centermost vertex. How can I maintain that continuity across the different squares?

# ¿ Aug 25, 2010 06:23

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

PDP-1 posted:

Assuming that the squares are laying in the (X,Z) plane and Y is up, just use the (X,Z) coordinates as the UV coordinates of the texture, and set the texture sampler to wrap mode. I'm not sure what you mean by 2x2 squares, but you may possibly have to scale a bit, like X/2->U and Z/2->V to get it to look the way you want.

It's more complicated than that. Imagine each square's surface is mapping texture coordinates from (0,0) to (1,1), such that in either direction the texture is repeated twice. But then I start deforming things by taking the centermost point and move it around. What do I have to do to keep the same scaling, but retain that continuity?

Actually a more interesting problem I think could be if I, say, dragged one of the end mid points up. Ehh let me scribble is out:

code:

+---+---+
|   |   |
+---+---+
|   |   |
+---O---+

Say I took the point at 'O' and I stetched it up while retaining the positions everywhere else. How can I ensure that I can have that shape but not distort the texture? I am expecting I have to start to split up this mesh to keep the 1:1 proportion of texture/surface, since stretching any of the points up or down in effect increases its surface area.

# ¿ Aug 25, 2010 18:24

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Generally in OpenGL can I index materials? I never ran into anything like that when I was manually doing OpenGL stuff awhile back, and messing with Irrlicht it doesn't seem to be obvious either. It looks like I have to go out of my way to change the material whenever I want, which means breaking up processing on something that could otherwise by a huge dump command to the GPU if I could give it all the materials up front.

# ¿ Aug 28, 2010 19:16

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I am trying to figure out what's going on with the viewing matrix that Irrlicht is using by default with it's absolute transformation (paraphrasing here). I put a camera at 0, 0, 30 looking at (0, 0, 0). I am finding that positive X values move leftwards. The Y and Z components look ok; positive Y moves up, and positive Z approaches the camera. At least I can understand that, but the X side kind of baffles me. How could I transform that matrix to make X move positive to the right? Or is the convention to have it go leftwards?

# ¿ Aug 29, 2010 04:49

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I don't know what to think of what I'm doing here so I thought I'd post here since I think the people on the Irrlicht forums are just confused.

My mind has wandered from doing some kind of tile-based level editor especially since I don't really care about tiles too much and the kind of game I want to do doesn't particularly care about them other than their ability to represent level data.

A decade ago (I freaked out thinking about that) I used to do a lot of Quake 2/Half-Life level editing with Radiant. Irrlicht can slurp up Quake 3 .BSP files so I went bonkers getting GtkRadiant building and made some stuff up.

If you don't know how level editing works in that format, the world geometry is made up of convex surfaces that have to be fully-enclosed. Lights are explicitly given, and then a light map is generated for all the surfaces in post-processing that gives all that eerie shadowing you'd expect.

Of course I neither want a fully-enclosed world nor all that shadowing, so I created two different maps that were enclosed in transparent surfaces, and skipped the lighting step so everything was totally bright. I found I could slurp both into Irrlicht and position next to each other such that they were seamless. I don't know if I'd collide at the transparent boundaries or not, but at least zooming around they could be glued together. My idea was to be able to represent my game world by linking up little sublevels together like this.

Radiant isn't perfect but I know how to use it and I don't have to write a level editor if I go with it, so I thought I could try it. Does this sound completely stupid?

I need to figure out if I can do lighting using Irrlicht after all despite doing no light map post-processing. I assume so but I don't know yet. If it insists on going full bright no matter what lights I decide to use, then... ehhh...

# ¿ Sep 5, 2010 07:09

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Is there a text library for OpenGL that doesn't involve wanting to throw things at other things really, really hard? I was hoping to render some text for some charting code, so I didn't want to go grab some full-fledged 3d engine just for that.

I started with OpenGL's own rasterization stuff. It was fine enough until the coordinates for the text went off the screen, so the rest of the text would just vanish.

I started screwing with FTGL and got a texture font up. Just for giggles I decided to push it and sent it a newline. It just put a garbage character there and blew it off.

So let's say maybe I wanted to render a box worth of text that might move around and even only be halfway on any particular part of the screen. Is there an OpenGL library that'll do the job without pulling in a bunch of stuff?

# ¿ Feb 17, 2011 08:25

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I see monsterland and OneEightHundred have experience in this. What sucks about this all though is how it appears those are the kind of hoops one has to jump through to work with text, unless one wants to drag in a whole other engine that has a heavyweight library for doing this kind of stuff. What annoys me is that we are here in 2011 and working with text is still such a huge chore in OpenGL. All those solutions shouldn't have to be necessary.

# ¿ Feb 18, 2011 08:19

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

OneEightHundred posted:

It's the spec's fault that they decided that vendors whose OpenGL drivers have not historically been of the highest quality should also be responsible for writing fully-functional compilers. As opposed to, say, using a SSA IL language that would be very difficult to gently caress up and would let users/developers decide for themselves what shading language they wanted to use.

I was thinking about your view here with a especially cynical state of mind today. Wouldn't an intermediate language just procrastinate the moment when the driver vendor gets to gently caress up? Maybe they don't blow it in a compiler, but instead they'll get to blow it when they screw up how they handle the intermediate language.

Events of late have been leading me to believe crappy developers will find new and innovative ways to write crappy code when given the chance.

# ¿ Feb 24, 2011 21:11

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Is there a good online primer about different model animation file formats and their limitations? I was toying around with loading and animating an MD2 model in Irrlicht and found it was a bit counter-intuitive. There is some concept of fixed actions that use a compiler enumeration, but it looks like there isn't something in the format for defining arbitrarily different animations. I assume most of the formats have their little quirks like that, so I hoped there was a programmer's primer for these so I can go in understanding all their little limitations.

# ¿ Mar 1, 2011 03:36

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

OneEightHundred posted:

Of the specialized formats:
- MD2 has terrible precision and experiences "boiling" artifacts on high-poly models. You should probably not use it.
- MD3 supports attachment points and is otherwise a pure vertex format, but it's easy to parse and better than MD2 for almost all scenarios.
- Epic PSK/PSA, Source SMD, and Id MD5 are roughly identical capability-wise. All three are simple skeletal formats that support simple orientation/position based skinning on one mesh tracked by frame with multiple weights per vertex. Of them, PSK/PSA are probably ideal as SMD doesn't store framerate and MD5 duplicates points across textures.

Thanks all for this and everything else. I guess I'll rant about what I'm experiencing since I think there's a question about what it is I'm trying to actually accomplish.

I thought I'd open up some models from the jDoom resource pack and make them do a little dance or something. I just knew it was a place that had lots of free models that I had seen before in years past. They are all stored in MD2 files. Using Irrlicht, I can load in and skin, say, the chain gun guy fine and dandy. Except that he has no gun. If I look at the model in Blender, it is there. Or at least the vertices are there; I couldn't get it to show any of the model(s) textured. Import the same file in Irrlicht, and it's gone. So I was trying to figure out how to attach the drat thing or get it to show up or what.

To make things more fun, Irrlicht seg faults when I try to load the gun model too. I haven't figured out why.

I'm assuming they made the gun removable to make it available as an item to pick up after the player kills the monster. But I see from the format differences is that it's a real pain in the rear end to attach it. I guess it's more of an illusion than actually attaching it. It's just coincidentally floating in the spot of the model's hand, as opposed to something like bones where the engine knows there is really a relationship between the main model and the gun.

Since I thought doing this would actually be easier I have concluded it's not helping and have about given up. So then I figured maybe I could model something really simple in Blender, like a cube person or something. Except that all the modeling videos are done by people talking through retainers that assume you already know how to use Blender, and basically imply you already know how to do everything they're showing anyways. So I've gotten a little bit frustrated. I have done level editing in Radiant before so I thought I'd have some basis for this, but I can't even figure out what views and magic keys I need to make a model with some basic animations.

And all this before I really write any code!

# ¿ Mar 2, 2011 20:15

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

HaB posted:

Can't help with your model loading/animating problem, but having ZERO 3D modelling experience myself, I set out to learn Blender and found this, which worked pretty drat well:

http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

I dunno about all the way to "Pro" but I definitely go from "Noob" to "Passable" using that.

This looks very complete. I might have to just hush up for a few days and read through a lot of that. I'm assuming after the smoke clears I can make a decent enough box person that I can run through various abusive animations in a 3d engine without much fuss. I have ton of tabs open where I just went off on tangents on things like adjusting the view or tweaking vertices because I couldn't find it all in one spot. This looks pretty much like what I needed.

# ¿ Mar 4, 2011 06:23

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I've read enough into the Blender n00b to pro guide to know a little bit about making some meshes now and animate them with bones in place. Now I'm thinking about how this stuff makes it over to an engine in some meaningful way. I was hoping for some modularity in particular. I am trying to use Irrlicht, but if another engine has solutions for what I was hoping to find, I'd look at it.

For all of these, I'm assuming a model of a humanoid character.

I was wondering how to manage things like holding different items without redoing all the animations for a model. I assume one can split the upper and lower body to some extent and just animate the upper body separately, but generally how does one accomplish this and have the engine know what to do?

Now what about a head that moves and turns and shifts eyes and possible opens it's mouth to feign speaking--which is the best I could ever expect to do myself. I assume there is some programmatic control here. Is there a general method for these?

Is there a way to define general animation with bones and have different humanoid meshes all use those animations? It would suck a lot to be forced to animate slightly different sized and shaped people over and over for each new one.

# ¿ Mar 11, 2011 21:26

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Do you know if Irrlicht has something for animation blending? I see something for blending one into another temporally but not necessarily for smashing together multiple animations at once.

# ¿ Mar 12, 2011 00:50

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Yes generally you have to be kind of creative. The puzzle stuff I always liked were clean and symmetrical in a way--I guess you'd say, "elegance." But if you're out of ideas, you could implement a generator that takes the game's rules, starts with the end outcome, and jumbles things according to the rules. The resulting puzzles will be probably be noisy and sucky, but if you try them on even just a small set you might see a few clever things come out as inspiration.

# ¿ Mar 15, 2011 18:54

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Maybe there taking a new spin on voxel terrain generation but I recall that was pretty common for 3d awhile ago.

http://www.mobygames.com/game-group/games-with-voxel-graphics/offset,25/so,1d/

There is newer stuff but it's interesting to see it split into 3 date spans: 2010-1998, 1997-1996, and 1995-1992. The mid-90's seemed to do a lot with voxels generally, although not necessarily with terrain.

# ¿ Mar 23, 2011 21:27

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

roomforthetuna posted:

The problem is, no matter how much you abstract away the GUI stuff (Windows has had a resource editor for ages that does what you describe!) you still end up having to go to code for the effects of every button, slider, etc. that does anything, and in a good GUI most of the widgets will do something.

(etc)

And to add on top of that, there's a good chance one will have to subclass/override/redo some of the more basic components to perform some kind of function more intuitively anyways.

# ¿ Mar 29, 2011 20:00

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Does anybody recommend something other than Blender for a free modelling tool? I was trying to model my backyard to scheme and render some ideas of how we want to change it. I have then wasted a full week figuring out how to put leaves on a tree using a leaf texture. The transparency just doesn't come out right. I just can't imagine it being that hard. The texture has alpha channels and Blender even acknowledges that--kindof. The shadows are screwed up and it won't do the transparency in the 3d view.

# ¿ Mar 31, 2011 14:48

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Bob Morales posted:

Why don't you just use 'home garden designer 2011' or something? Shovelware easily found online or at Best Buy/Walmart.

quote:

Google Sketchup is free (for the basic version) and has a thing called 3D Warehouse where people can upload models of all kinds of stuff. A quick search for 'tree' returned 8950 free tree models. It can handle transparency and shadows. You can export the result as a COLLADA file if you want to import the model into something else.

The goal is to ultimately learn how to use Blender so I can DIY some 3d models and stuff for making toy game projects and such. I already use it for video editing on Linux. Oddly enough it worked the best and (most surprisingly) had the UI I could most understand.

...at least for video editing...

I was thinking the trees and stuff I intended to make I'd ultimately want to try to export and put into Irrlicht or something.

Anyways I did get a response back from blenderartists.org. I have yet to try it, but it's so unintuitive that it's bound to work. Did somebody say they cleaned up the UI? I may not be a modeler but I understand most all the 3d rendering nomenclature, yet how one has to approach stuff in it is so bizarre. On a different Blender topic, it's reliance on keeping everything as quads seems especially strange to me. Don't other modeling programs work fine with triangles?

# ¿ Mar 31, 2011 22:15

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I had thought sketchup ran in the browser so I was going to lament how Google can use a bastardized technology to create a 3d editing UI superior to client-side stuff, but then I saw it was a downloaded application. But it's still kind of telling that a company you wouldn't expect to care about 3d like that would make something so intuitive. Then again maybe one needs to be a little dissociated from it to make something more accessible; everybody else just gets used to the same crappy UIs.

quote:

I think quads are better for most subdivision surface algorithms.

Is this a general practice across 3d modelers then? It just surprises me after years of thinking in terms of triangles to then see an obsession over quads.

quote:

ngplant

That's pretty neat. For what I'm doing at this immediate time it might not be the most useful since for the backyard modeling I'm trying to get the big branches in pretty specific spots; we're interested in how it shades everything over the course of a day. But for creating game assets, having some kind of tool would be much more useful for cranking out a variety of trees.

# ¿ Apr 1, 2011 20:17

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

For anybody that's good with programming and have the general idea of game engines down, but are still daunted by the whole thing, I'd recommend playing with a modeler for a little bit. My big problem with games has been imagining the whole "meshes bumping into meshes and interacting with other meshes" that makes up a lot of the 3d side of things that seems too daunting to me.

To that end, I was wondering how pervasive pixel shaders are these days for replacements for textures? If that's not how they're being used then how do they get to be such a hot item? I can understand things like normal mapping and cell shading, but outside of that are they just being used for the shiny?

What got me thinking about this was all the stuff in Blender for generating materials in Blender procedurally. I wondered if instead of dealing with a bunch of wood textures if people instead are just applying a wood effect shader. Stuff like that.

# ¿ Apr 6, 2011 20:50

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Gerblyn posted:

Are you talking about collision detection here? I'm a bit confused how you got from this sentence to questions about pixel shaders...

Hah I can understand the confusion. I didn't mean to infer one directly lead to the other. I don't even necessarily imply that collision detection is particularly a thing. I am more thinking about being able to have meshes of significant complexity and detail and be able to have them interact with stuff. It's one thing in my mind to understand them all as different entities and know how to move them around and stuff, but it's something else to go that last bit and have meshes representing them doing their thing. That's where I was getting overwhelmed.

Blender's been a real pain in the butt, but it has been useful to, say, add bones to a model and move it around, and apply UV texture coordinates and the like. Another example would be the idea of putting a weapon in a model's hand. Conceptually it's easy enough to imagine assigning the weapon and such, but making it really work is something else. So seeing how they do that in a modeler has gone a long ways towards knowing how I should approach it in a game.

# ¿ Apr 7, 2011 06:30

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Paniolo posted:

Is it just me or can blender and assimp not agree on a single file format that supports animations? Assimp's .blend importer doesn't import animations, Blender's collada exporter doesn't export them. I've tried exporting .3DS and .X and both of them just produce error messages (or silently fail and write empty files.) I even tried exporting as .FBX and importing that in 3DS Max, but the FBX model was filled with garbage. What the heck is wrong with Blender?

I'd like to import some models in my engine that aren't sourced from commercial games but everything I can find in the public domain is in .blend format.

I blew a week's worth of my free time--arguably not much--trying to get stuff from Blender to export into Irrlicht. I think I need to add a technical category to my little cooking website blog where I can dump down all the stuff I figured out while doing that. It's a bit of a mess.

What I had done:
1. Updated to Blender 2.57. That's the first 2.5 stable release. I am finding myself much more successfully using it generally.
2. Get the DirectX import/export add-in registered in the user preferences because it doesn't like to be there by default.
3. Make sure the model's bones have vertex groups in the mesh assigned to them. What this means is there there should be a vertex group per bone in each mesh, and there should be vertices attached to the bones for each. This is a big deal. Even if Blender can BS the movement in pose mode, the exporter won't export a skin w/o the vertex groups.
4. Bake the location and rotation transforms into the model. I think that's under shift+a. I think the term is "baking" for this anyways. It could be that the model was represented by a certain location+rotation matrix, but has since been moved around. So what you see in Blender won't be what you get out of the exporter.
5. Make sure there are actually some keyframes that would be animated. Look in the dope sheet for some function curve points.
6. Export with the DirectX exporter. You want to make sure to export the armature. They said that if you applied the armature as a modifier, then the "Apply Modifier" option should work, but I haven't necessarily had luck with it. Also make sure to export to export the keyframes only, or full animation. I have had both work for the basic thing I did.

I figured all this out while getting halfway into writing an XML-based file format for exporting animated meshes. I still want to do it to fully understand how animation is represented generally, but it is a very complicated topic and none of the code in the exporters are self-documenting. In fact the bastards can't seem to find the # key to put in some nice comments.

I also want to do it because I am thinking of using Blender as a level editor, and I want to be able to export out game entity data from it in some planned way.

# ¿ Apr 18, 2011 16:46

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I spent my home nerd time the past few days learning how to wrap C++ code for the sake of Python. The goal is that I'd like to be able to doodle around in Python and prototype game logic there while the stuff I've chosen to use for graphics and sound and all sits in C/C++ land. I've having a hard time figuring out where to draw the line in what I should do in the interpreter and what to initially manage externally.

At first I thought I'd try to write wrappers for everything and have it all start up in Python, but a few days in and I was still crawling down the rabbit hole just to get something basic all wrapped. So I think I have opted to tie up the rendering engine into my own separate object and pass garbage into it as I see fit.

There was some talk previously about representing game logic objects with some master Entity class. I am wondering how one manages and passes them around. My first thought is to just toss these over to the rendering engine and have it try to figure out what to do with them. So the entities would at some point in their representation would need to have some mesh in it and enough state that the renderer can set it all up at that instant.

So I am assuming the main currency of the different components of the game engine would be these entities. Is that the general idea?

# ¿ May 16, 2011 19:15

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Anybody here played around with the Bullet physics library? I was asking some of the Irrlicht people for examples of collision detection for making sure entities don't fall through the game world but do honor gravity, and pretty much they steered me right to that. I assume it's because of the Irrlicht bindings that come with it. The response seemed a little :smug:

at the time but I guess it makes sense; I'd probably end up bringing in physics in some fashion so I might as well grab the bull by the horns. It did solve my problem in just a few lines of code. But I wonder if I'm going to get into a quagmire when I try to do stuff like check if stuff is successfully smacking down other stuff, projectiles, or generally other stuff that might happen in a game I haven't tried to do.

# ¿ May 26, 2011 19:18

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I have an odd problem with rotating stuff when a physics engine is in the way--particularly Bullet here. I wrapped the model representing the player up in a sphere and put it into Bullet's little physics world. I am using a joystick to try to move the player around. Once Bullet has a handle on the model, I can't just rotate or reposition it in Irrlicht; I have to apply forces. For simply translating in space, I provide a linear velocity. But when the player starts moving in a different direction, I want the player to face that way. So I have to apply an angular velocity. But I don't know exactly how much to provide since I don't have an idea when the next frame will come along. I could just as well undershoot as overshoot.

Right now I'm just applying a constant velocity, and implementing a dead zone so that it stops if it gets roughly in there. It kinda sorta works but it still can be jittery.

Also I could take any tips on finding the best angle to use to steer the player around. Given I know the player's current angle and the target angle, is there a trig one-liner to give me the best angle to use in turning at that moment? I'm thinking something like a positive angle implying clockwise and a negative one implying counter-clockwise.

Edit: Confirmed calculating how much to turn is bull simple. Turns out there's something odd going on in the engine when I try to go in a direction increasing between 90 and 270. It gets all jittery there even though when I did a little table to show the math all the correct angles were there. So I have to see a little more what it thinks its doing in those ranges when I ask the engine what angle it thinks the player is facing.

Rocko Bonaparte fucked around with this message at 19:28 on May 28, 2011

# ¿ May 28, 2011 18:40

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

PDP-1 posted:

Are you using an arccosine function to calculate your angles? If so your jitter problem might be caused when you pass through the 180 degree mark and the result of the arccos function switches between interpreting this point as -180 degrees as you come from one direction vs. +180 degrees as you come from the other direction.

If that's the case you just need to add some extra logic to detect when the target and facing vector angles have different signs and adjust one of them by +/-2*Pi so that they both have the same sign.

Looks like you were generally correct about the problem, although oddly enough it really only seems to come along when my target direction is in the second and third quadrants. In my case I'm not doing a cross product of vectors and then arccos. I was trying to exploit a peculiar situation of the game that it is generally top down, so I just looked at the Y component of the players rotation vector that Irrlicht is maintaining. I'd then compensate if the result was greater than 180 or less than -180 by switching the direction, like this Python code might show:

code:

def calc_angle(current, target):
    diff = target - current
    if(diff < -180):
        return 360 + diff
    elif(diff > 180):
        return diff - 360
    else:
        return diff

So if the current direction is roughly 180 from the target, then there is indeed a sign change. I think the problem stems from the angular velocity. It doesn't take a nap between frames but rather continues to assert itself, so I think I run into a situation where on paper it should go the other way, but with the current velocity it's going to get to the target sooner the way it's going. So with that little lag it's getting shuttered back and forth.

# ¿ May 29, 2011 00:56

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Luigi Thirty posted:

What are some good books for learning OpenGL with C?

I suppose if you want to look at OpenGL in isolation, then the Red Book is the big one:

http://www.opengl.org/documentation/red_book/

Re: my rotation stuff, it looks like I have a larger problem I didn't notice until I slowed the whole thing down. Let's say zero degrees represents north, and 90 degrees represents east. I start my model out facing north and tell it to go to 120 degrees by moving clockwise. I am printing out the Y component of the models rotation vector as it moves to see what it's thinking, and I see stuff like this as it moves clockwise: 0.... 30.... 60.... 90.... 60.... 30.... 0....

How is it that after the 90 degree mark that this angle would begin to decrease while still rotating clockwise? I am so confused.

Edit: I looked at the whole rotation vector and noticed that it was running at (0, Y, 0) and then switched to (180, Y, 180) right when it crossed over at 90 degrees. So sad. I assume this is Bullet's doing :colbert:

Rocko Bonaparte fucked around with this message at 04:18 on May 29, 2011

# ¿ May 29, 2011 03:52

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Internet Janitor posted:

If you're ever trying to convert cartesian coordinates to polar (or the equivalent), use Atan2. I've seen this wheel reinvented more times than I can count.

Thanks for this. It's a bit cleaner than what I was coming up with. However, I think the start of all my trouble was something else.

Say I have figured out how much I need to turn and which way, so I have it start turning. I am trying to figure out now how to be sure I got there, given the rotation vector is in 3d and somewhere between Bullet and Irrlicht it likes to play cruel games with me. So imagine the player has started by facing north and I want to turn 135 degrees (southeast). I'm seeing the rotation vector do stuff like this:

(0, 0, 0)
...
(0, 30, 0)
...
(0, 60, 0)
...
(0, 89, 0) ... Right around 90 degrees something stupid happens
...
(180, 89, 180) ... the player is rotated 91 degrees here
...
(180, 60, 180)
...
(180, 45, 180) ... This is what I can see as 135 degrees

I think it's Bullet that is doing it since it seizes control of position and rotation. It also seems to be still doing the right thing when given an angular velocity. I just can't figure out mathematically how to prove I'm getting the correct angle from that pile of stuffs.

# ¿ May 29, 2011 18:48

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

PDP-1 posted:

Longshot guess here since I know nothing about Irrlicht - when you generate your View matrix do you use [0,1,0] as the 'Up' vector (or [0,90,0], however its defined). If so, you may be running into problems when the way the direction the player is facing is equal to 'Up' since constructing the View matrix usually requires taking the cross product of the two directions so if they are the same vector the result is zero and weird poo poo starts to happen.

From what I can tell from the camera I am using, the up vector is indeed [0, 1, 0]. But what should I be doing instead? Here the camera is in effect looking down at the world as something rotates around its Y-axis.

# ¿ May 29, 2011 21:09

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I have some more physics questions, having hacked through some more Bullet stuff; I think I found a bug in the Irrlicht wrapper that I worked around and I don't know why the (0, y, 0) -> (180, y, 180), but I've worked around them. I am wondering now how collision is generally done for, say, melee attacks. Right now my player model and my enemy are wrapped up in spheres, and that does a decent job of keeping them on the ground. But now I have it set up so the player can hit a button and take a swing. The animation for the swing exits the bounding sphere. How are collisions generally handled here with an enemy?

It's going to feel like crap if the hit only registers if, say, I have hit the button while the two spheres are in contact. Because the enemy could very will toggle their animation too and we'll be pelting away at each other without the swords from other animation actually touching anything. Is this where you switch to a more specific binding method to test collisions? Or generally is it still approximated?

# ¿ Jun 1, 2011 08:59

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Hughlander posted:

You can put a bounding box around the weapon itself, and test if that box intersects the sphere. If it does then you can do a closer test to see if it hits the model itself, (possibly or not taking into account the current animation) and then treat it as a hit. Games I've worked on in the past used two bounding boxes around the model for the gross scale world tests, then used a capsule system around the animation nodes for the fine grained test of 'did it really hit' and 'what did it hit'

How was the weapon bounding box information fed into the engine? Was it a part of the model, or was it calculated in real time? Or something else?

# ¿ Jun 1, 2011 19:34

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Gerblyn posted:

This method is fairly hardcore, and is only necessary if you're making a game where such accurate collision actually matters, i.e. You want characters to be able to duck under the sword, or side step a downwards strike or something. A much easier method is to define an impact point in the sword swing animation (say at 0.2 seconds after the animation begins), and when your animation reaches that point you put a collision sphere in front of the character swinging the sword and say "everything touching this sphere got hit by the sword". This is much computationally cheaper as well.

My 3d matrix chops could be better but I have the basic idea of what you're saying. Something I'm wondering is how I'd be able to get the Bullet library to play ball with that. Basically, how to tell Bullet all the physics is coming from the animation, and it'll have to figure it out from that. But I suppose having a contact box show up mid-animation is a smaller version of the same problem, so I'll concentrate on that first. You're correct I really don't need to get into that kind of detail, but it got me thinking about things like being able to handle clothes on characters and stuff like that if I was feeling fancy.

# ¿ Jun 2, 2011 23:20

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

slovach posted:

I think I have an idea how to do it. I'm guessing the road is drawn in strips and it's shifted over to make it look like its turning. No idea how to handle the dips and bumps but the basic perspective and turns doesn't look difficult.

I think you are right about the strips. Dips and bumps would be pretty simple if you render back-to-front. Just put each strip at the appropriate height. I think the big thing is to be able to handle some of those more excessively long turns.

# ¿ Jun 6, 2011 06:33

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I recall awhile back asking about collision detection for a character doing something like a melee attack. One suggestion was to generate a bounding sphere in front of the attacking character at a certain point. I'm trying to figure out how to do that right now. I can set things up so that during a certain frame range I have some stuff active, but I can't figure out between Irrlicht and Bullet how to create an invisible volume that can report back to with what it collided.

I assumed Bullet would have some capability for this. The problem is that the volume has effect on the surrounding objects no matter what. So it's knocking stuff around while it's active, and everything tries hard to keep from occupying each other's spaces. However I want this to be a space that could be occupied--that is really the whole goal. Does anybody using Bullet for physics have an idea on how to set it up to do these kinds of tests?

Edit: I guess what I need are Bullet's "ghost objects." The wrapper I'm using doesn't support them so I'm trying to write a wrapper for them.

Rocko Bonaparte fucked around with this message at 15:30 on Jun 29, 2011

# ¿ Jun 28, 2011 17:12

Adbot: ADBOT LOVES YOU

# ¿ May 5, 2024 11:09

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I'm halfway into doing some kind of component-based design for a little game engine, and here is where I am getting stuck and needing to make sure I even fundamentally understand what it means to use that kind of design. It's been easy enough when I was working with graphics, physics, and audio generally, but when it comes down to specifically controlling entities, it all becomes a mess in my head. This is because now I'm dealing with different subsystems that could actively compete for the entity's attention and influence it in different ways.

For the sake of discussion, imagine an entity that could be controlled in a few different ways. I am going to list a ton of ways--some of which I personally might not use. However, I think the more the merrier in trying to understand how to organize all this stuff:
1. Player is controlling it directly.
2. AI is controlling it.
3. Maybe a scripting engine is making it do some acting stuff for cutscene crap.
4. Somebody remotely is controlling it--network is managing it.
5. Maybe it's in demo mode and is playing back a sequence of events.

So right now I have a subsystem for controllers and am working on one for AI and basic scripted events. But without knowing any better I'm not sure how to arbitrate the different methods of control. I thought the original idea would be for all three, I'd have a subsystem with its own callbacks. The callbacks would state what to do next with the entity. I guess then the entity would need to know which one it's actively being controlled by, and ignore stuff from everybody else.

If I'm ignoring the other callbacks, I wondered instead that most all these could go through some common callback, and the entity or something else would tell all the other subsystems to stop calling back.

Since this is pretty messy, you can ignore the lot of this and just talk about how you'd approach multiple avenues of controlling an entity. That would probably be a good start.

# ¿ Jul 6, 2011 06:53

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›22 »