Ghosting Limits

#101 Sweet, that was fairly painless. I just created a tad bit simpler texture atlas with only 4 sections, so that I could do the initial tests in increments of 0.5 :
My intitial test I used this:

Point2F( 0,  0), Point2F( 0, -0.5),
	  Point2F( 0.5,  0), Point2F( 0.5, -0.5)

...which gave me this:

Then I ran another one to be sure, this time aiming for the top right(dirt):

Point2F( 0.5,  -0.5), Point2F( 0.5, -1),
	  Point2F( 1,  -0.5), Point2F( 1, -1)

I got this:

Boom! Success :D The edges of the 2nd run seemed to have perhaps a single pixel from the neighboring tiles but I figured this may be easily corrected with a 0.6 value. With a texture atlas thrown together so quickly, I can see many ways of optimizing this.

#102 0.6 would work if you were dealing with 10x10 pixels....

Remember, 0.0 to 1.0 is 0 to 100%, or 0 to 127 (on a 128x128 texture), so dialing that in might be a little hairier than you were thinking - but only a little.

Looking really cool so far!

#103 Ah yes, you make a valid point. Thanks Richard!

#104 Awesome job so far Jesse! Lookin' very nice. Just keep plugging and chugging away and learning, and soon enough you'll have one fantastic game :)

@andrewmac that info is invaluable. If i ever decide to do something regarding a cube based world, def. coming back to this thread haha.

...maybe I can make Cube Blast afterall....(#insideJoke)

#105

Quote:Remember, 0.0 to 1.0 is 0 to 100%, or 0 to 127 (on a 128x128 texture), so dialing that in might be a little hairier than you were thinking - but only a little.

Hmm, obviously I'm overlooking something here. No matter how I try to calculate this I keep getting the same results. Take the dirt in the above texture; to the left is sand and below is grass. If I use 0.5 or 0.6 I'm still seeing a single pixel line of the neighboring texture. I don't think it's the calculation...by all rights, no matter what the pixel dimensions are 0.5 is always equal to 50% (since our scale on the UV is always 0 to 1). There's an underlying issue here with creating an atlas texture it would seem..unless I'm just completely overlooking how to calculate this. Open to suggestions.

#106 You seem to be doing quite well with this stuff, so I don't think I need to go too in-depth about what I did here:
gist.github.com/andr3wmac/f32a3674abd994de640c

Screenshot:

I created a struct called Cube which has two members, position and materialNum. I don't think I can do nearly as well of an explanation on structs as something like this:
www.learncpp.com/cpp-tutorial/47-structs/

It's just a simple data structure. I switched my vector to hold the structs. I simplified adding cubes to the list by creating a addCube function. Changed over the default cube creation to use that function, and expanded the cubeTexCoords array into a two dimensional array:

static const Point2F cubeTexCoords[4][4] = 
   {
      // Red Cube ( Top Left )
      { Point2F( 0, -0.5 ), Point2F( 0, -1 ), Point2F( 0.5, -0.5 ), Point2F( 0.5, -1 ) },
 
      // Green ( Top Right )
      { Point2F( 0.5, -0.5 ), Point2F( 0.5, -1 ), Point2F( 1, -0.5 ), Point2F( 1, -1 ) },
 
      // Blue ( Bottom Left )
      { Point2F( 0, 0 ), Point2F( 0, -0.5 ), Point2F( 0.5, 0 ), Point2F( 0.5, -0.5 ) },
 
      // Orange ( Bottom Right )
      { Point2F( 0.5, 0 ), Point2F( 0.5, -0.5 ), Point2F( 1, 0 ), Point2F( 1, -0.5 ) }
   };

You could expand that to hold as many entries as you have on your atlas. Here's where the createGeometry was modified to use the new Cube struct:

pVert[vertIdx + i].point    = (cubePoints[vdx] + cubeList[n].position);
         pVert[vertIdx + i].normal   = cubeNormals[ndx];
         pVert[vertIdx + i].texCoord = cubeTexCoords[cubeList[n].materialNum][tdx];

It now adds the position member of the current cube, and chooses the set of UV coordinates based on its "materialNum". Not sure about the name on that, it might cause confusion since it's all the same material, but whatever.

#107 Nice Andrew, already this looks to make a good bit of sense. I'm going to work through all of the changes now to solidify this in my mind. Did you also notice the 1 pixel problem along the edge of the textures? It appears you declared the UV Coords in the same way I did above. Although based on your images, your texture has a black line on the edges kinda like a buffer. But if you have tileable textures this may be a problem. Hey thanks, already I am seeing more clearly the creation of structs and how to expand on that UV set! Cool stuff, I'll report back after I go through this real good.

Quote:Just keep plugging and chugging away and learning, and soon enough you'll have one fantastic game :)

Thanks man, although getting there with the cubes and all is only half the battle. So many cube-based games mimicking Minecraft these days, most gamers just go ahead and dub the game a 'clone' at first glance. I've got some real good plans around making this not the case at all, but it's definitely going to take a lot of work!

EDIT: Thank goodness your 0.5 UV points are as I'd imagined them! I was going crazy thinking that somehow 50% was not 50% based on pixel size...lol (see post #102, 103, and 105 above).

#108 This is pretty fantastic, you guys. Also, nice textures Andrew ;). Extra credit: add top/bottom textures (maybe top/bottom have the same texture and sides have another texture) to the atlas.

Also, as an aside, breaking your terrain into multiple SubMatrices, each of which is a separate Torque object, will have other benefits. Andrew's already mentioned that you'll be able to render less, but you'll also get collision optimisation for free thanks to Torque's binning system. Whereas if your entire terrain was one object, you'd have to do some complex optimisations for collision checking, this way you'll probably be able to skip most of that, and just implement collision simply.

#109 Well, 0-49, 50-99...

Or maybe some variation thereof?

#110

Quote:Also, as an aside, breaking your terrain into multiple SubMatrices, each of which is a separate Torque object, will have other benefits.

If you look at post #101, you'll notice my object is named 'Submatrix'. :D This is definitely the plan Danny!

@Richard: Yes, of course. I get that there are multiple ways to split up numbers. But in this case there is some sort of rendering issue that arises when you split up a single material's texture. I don't know how else to explain that without you literally rendering this stuff out and taking a good look at it. There is always an added pixel edge that shows up; it's in my images as well as Andrew's. Regardless of pixel size though, 0.5 = 50%. In the light of recent events, with all of this clarity being packed into a single thread...please if you have a solid solution be a little less cryptic (just this once :D). Failing that, I'm going to have to assume this is some result of splitting the single texture in one material. Obviously this is all new to me, so there's a ton of room for error. I've always been of the mind that you can't argue mathematics, so if there is a mathematical solution I'm all ears.

#111 That kind of stuff can crop up with texture atlassing. I believe it's called the half pixel correction. Short answer: don't use exactly 0.5. Offset it slightly to fix the problem.

Longer answer: the edges need to be corrected by half a pixel. So where we'd normally think of it as 512 divided by 1024 = 0.5, it should be 512.5 / 1024 = 0.5004883. You can either work these out or make a function to do it for you.

It's confusing to think about but 0.5 specifies exactly in between the two pixels in the center, so it blends between them. Weird concept, I forgot about that with atlassing, sorry.

#112 No worries Andrew, what you've said all makes sense. I've had some distractions here at home(bless them all :P), but I'm finally sitting down again to eagerly make these changes to my files. I'm not just blindly yanking the provided code, I'm applying this stuff line by line. I'm sure you'd expect no less of me after all the effort you've put forth here. Thank you so much Andrew! I'll report again when I get this done on my end :)

#113
A picture speaks a thousand words! That was very cool Andrew! I am extremely excited at this point. The way you setup the new struct and stuff really helped me to understand a bit more about what I'm doing in C++. Hands on practice right there for sure :D I followed your example and was able to grasp all the new material pretty easily. Honestly, I spent more time fighting the conflicting coordinate values of C++ and Torque (i.e. the difference in y and z when translated from C++ to Torque lol).

I'm going to dig in and try to meet the challenge Danny set forth above for extra credit and see if I can get that working. Additionally I'm going to dig a little deeper and try to line out that 0.5 offset.

#114 Yeah - aliasing - that thing... lol - I was flailing about madly and for some reason couldn't get it through the keyboard. T2D does this too in animations, if you're not careful (it might have been fixed).

#115 Was up a tad later than I should have been, but I got real close to getting extra credit. I added a new variable to the Cubes:

submatrix.h

...
   // List of cubes.
   struct Cube
   {
	   Point3F position;
	   U32 materialNum;
	   U32 materialNum2; // new material here for top
   };
   Vector<Cube> cubeList;

   // Simple function to add cubes to the cubeList.
   void addCube(F32 x, F32 y, F32 z, U32 mat, U32 mat2); // also here
...

I added the new value in submatrix.cpp:

...
   // added 5th number for new material
   addCube(0, 0, 0, 0, 1);
   addCube(1, 0, 0, 0, 1);
   addCube(2, 0, 0, 0, 1);

   addCube(0, 1, 1, 1, 1);
   addCube(1, 1, 1, 1, 1);
   addCube(2, 1, 1, 1, 1);

   addCube(0, 2, 2, 2, 1);
   addCube(1, 2, 2, 2, 1);
   addCube(2, 2, 2, 2, 1);

...

void Submatrix::addCube(F32 x, F32 y, F32 z, U32 mat, U32 mat2)
{
   Cube newCube;
   newCube.position.set(x, y, z);
   newCube.materialNum = mat;
   newCube.materialNum2 = mat2; // new material for top
   cubeList.push_back(newCube);
}

Finally I tried to add an if statement within our for loop to catch primitives 9 and 10, but ultimately couldn't figure out how to determine the exact primitive:

...
	// jesse - need a way to determine primitive #
		 int currentPrim[j] = 

        // jesse - determined the primitives are 9th and 10th on the cubeFaces index, 
        // but we are looping through 36 points when indexing and never setting up
        // an index per primitive 
		 if (currentPrim[j] = 9 || currentPrim[j] = 10)
		 {
			pVert[vertIdx + i].point    = (cubePoints[vdx] + cubeList[n].position);
			pVert[vertIdx + i].normal   = cubeNormals[ndx];
        // use mat2 here if we are on prim 9 or 10
			pVert[vertIdx + i].texCoord = cubeTexCoords[cubeList[n].materialNum2][tdx];
		 }
		 else
		 {
         pVert[vertIdx + i].point    = (cubePoints[vdx] + cubeList[n].position);
         pVert[vertIdx + i].normal   = cubeNormals[ndx];
         pVert[vertIdx + i].texCoord = cubeTexCoords[cubeList[n].materialNum][tdx];
		 }
...

Here's what I mean by 9th and 10th primitives:

...
   static const U32 cubeFaces[36][3] = 
   {
      { 3, 0, 3 }, { 0, 0, 0 }, { 1, 0, 1 }, // 1
      { 2, 0, 2 }, { 0, 0, 0 }, { 3, 0, 3 }, // 2
      { 7, 1, 1 }, { 4, 1, 2 }, { 5, 1, 0 }, // 3
      { 6, 1, 3 }, { 4, 1, 2 }, { 7, 1, 1 }, // 4
      { 3, 2, 1 }, { 5, 2, 2 }, { 2, 2, 0 }, // 5
      { 7, 2, 3 }, { 5, 2, 2 }, { 3, 2, 1 }, // 6
      { 1, 3, 3 }, { 4, 3, 0 }, { 6, 3, 1 }, // 7
      { 0, 3, 2 }, { 4, 3, 0 }, { 1, 3, 3 }, // 8
      { 3, 4, 3 }, { 6, 4, 0 }, { 7, 4, 1 }, // 9th primitive!
      { 1, 4, 2 }, { 6, 4, 0 }, { 3, 4, 3 }, // 10th primitive!
      { 2, 5, 1 }, { 4, 5, 2 }, { 0, 5, 0 }, // 11
      { 5, 5, 3 }, { 4, 5, 2 }, { 2, 5, 1 } // 12
   };
...

So I feel as though I kinda got close, but since we're looping through all 36 verts and not the primitives I'm not too sure on how to determine we're currently at the right primitive. In hindsight, maybe some additional for loop ahead of time just to index the prims would work? Do I maybe get partial credit? Cheers!

#116 Heh, I think I should have been following along with the tutorial by hand - looks like that extra credit is harder than I thought to implement! Though it looks like you're on the right track. But think about it - if every primitive is three verts, and you have the vert index, what is the primitive number?










floor(vert number / 3)

#117 Well, if you plan on doing a lot of different textures for sides of the cubes, you may want to come up with some kind of side determining algorithm, but if you're just trying to get the top different, I would just just check i (your current position in the cubeFaces array) to see if it's within one of the entries you're looking for. You marked off the 9th and 10th primitives. 9s entry is 24, 25, and 26 in cubeFaces and 10s entry is 27, 28, and 29.

So:

if ( i >= 24 && i <= 29 ) 
  pVert[vertIdx + i].texCoord = cubeTexCoords[cubeList[n].materialNum2][tdx];
else
  pVert[vertIdx + i].texCoord = cubeTexCoords[cubeList[n].materialNum][tdx];

#118

Quote:Heh, I think I should have been following along with the tutorial by hand - looks like that extra credit is harder than I thought to implement!

That's completely alright Danny. It's forced me to really dig in and pay attention to what I'm doing, as well as focus on the material I've been reading on the C++ site. Declarations, proper syntax; it only serves a greater good in the end. This stuff is sinking in!

I also want to be sure I impress my tutor, so that he continues to illuminate me lol :P


@Andrew:Gotcha! Gosh I should have caught that. I totally get it now. I was looking at the faces and the texCoord use all in the wrong way. The exercise has forced me to look closer, though, and that is a good thing :)

Well I'm not sure how far you were going with all of this, but if you can help me add collision and some sort of raycast function to pick out cubes I believe you've nailed the entire terrain problem! Maybe some suggestions around culling methods could go a long way as well :)

#119 Awesome, looks like it's working as planned. I'm not at home right now so I can't actually use torque, so I'll dump the info on collision later tonight when I get home after I test it out to make sure I know what I'm talking about.

In the mean time though, I can show you how to expose some functionality to TorqueScript, since I imagine you'll still be managing a lot of this from TorqueScript. The idea of exposing functions to TorqueScript is pretty damn simple. You just need to know the syntax. Here is an example of the layout:

DefineEngineMethod( CLASS NAME, FUNCTION NAME IN TORQUESCRIPT, RETURN TYPE, ( PARAMETERS ), DEFAULTS?, "DOCUMENTATION DESCRIPTION")
{
   object->ACTUAL FUNCTION(PARAMETERS);
}

You need one of these (filled out with proper values) for each function you want to be exposed to TorqueScript. These go inside your .cpp file, there's no need to add anything to your .h file, and where you put it in the .cpp is not important. If you don't fill out one of these and place it in your .cpp file, the function will only be accessible from C++. Here is an example of it filled out for the addCube function:

DefineEngineMethod( RenderMeshExample, addCube, void, ( F32 x, F32 y, F32 z, S32 matNum ),, "Adds a cube to the ")
{
   object->addCube(x, y, z, matNum);
}

"object" is a reference to the object in question that you're talking about it. Just think of it as a helper to let you do something to the object torquescript is targeting.

After putting something like this in place you just need to get ahold of your object in torquescript and then you can do:

%myCubeThing.addCube(10, 10, 10, 0);

You can do this with as many functions as you want. Once we get collision and raycasting in there, you should be able to cast a ray from the players view and it'll return the position you hit in the world. You could then use to determine where to add/remove cube from. I'm hoping to see all that functionality handled in script.

One thing to note: createGeometry is only called once soon after the object is created, so changing the cubeList via addCube won't update the object. You could stick a call to createGeometry into addCube, but then you're gonna rebuild the buffers every time a cube is added (which would be a waste if you add like 50 cubes at once).

Perhaps the best approach would be to expose createGeometry to torquescript (maybe just call it refresh() for torquescript, then have it call object->createGeometry();) then you could do:

%myCubeThing.addCube(0, 0, 0, 0);
%myCubeThing.addCube(1, 1, 1, 1);
%myCubeThing.refresh();

Of course a lot of these specifics are up to you, whatever matches your design/vision the closest, just try to keep optimization in mind. You want to minimize rebuilding those buffers as much as possible as it'll start to show a cost with massive amounts of cubes.

#120 Really cool! So far, I've already been using a DefineEngineMethod for the actual Submatrix object. It was just there already for the RenderMeshExample. Although I was just kinda blindly depending on it to work, without looking closer and realizing what you just outlined for me. This is beginning to become clearer, as I'm starting to see now how this particular usage can affect the Submatrix object in the long run. The biggest disconnect for me had been wondering how on Earth were we going to interact with cubes within the larger Submatrix object when all of the geometry is recognized as just one big object in Torque. I believe I (sort of) see where you are going with this. I'm kinda looking through the undergrowth atm, but I know all will be clear once I break free!

Quote:Once we get collision and raycasting in there, you should be able to cast a ray from the players view and it'll return the position you hit in the world.

Very exciting indeed! In my case, though, I'll be wanting to try to cast the ray from the camera and select the cube under the mouse pointer (isometric view). I've achieved this in the past with script, but not sure yet how this all will tie into this particular application.

I am definitely not opposed to handling stuff in script, haha! That just makes it easier for me to manage, of course. I'm going to mess around some with DefineEngineMethod and see what sort of stuff I can come up with while I wait for you to show me a few more pages in the 'Book of Uber Knowledge'. :D