Suspicious Dish posted:

Compare with:

C++ code:

  auto const transformed_point = position;
  transformed_point.scale(2.0, 4.0, 0); // I'm assuming width = X and height = Y, but who knows.
  transformed_point.translate(-0.5 * meters, 0, 0); // left = negative X
  transformed_point.roll(60.0 * degrees);

Orzo posted:

I don't follow. What would be an example of something that doesn't use 'x/y' or 'x/y/z'?

OneEightHundred posted:

Don't use transform-in-place in C++.

C++ code:

  auto const transformed_point = position.scale(2.0, 4.0, 0).translate(-0.5 * meters, 0, 0).roll(60.0 * degrees);

Splat posted:

What's your reasoning?

Suspicious Dish posted:

This is the reasoning that bugs me. I'm certainly not going to use this library, but it's possible that a colleague does, or a former colleague does. My programming philosophies are aimed at designing APIs and making code that's simple to understand, even if it means it's a bit verbose. And if something goes wrong, I have to step through template madness in my breakpoint debugger, cursing at whoever did this.

Suspicious Dish posted:

C++ code:

  auto const transformed_point
    = transform( scale( width = 2.0, height = 4.0 )
               , translation( left = 0.5 * meters )
               , rotation( roll = 60.0 * degrees )
               , position                           // What to transform
               );

There's lots of assumptions here, like what space we're working in, and what order the transformations are being applied in (the source is at the end, so does that mean we work backwards?)

Suspicious Dish posted:

Compare with:

C++ code:

  auto const transformed_point = position;
  transformed_point.scale(2.0, 4.0, 0); // I'm assuming width = X and height = Y, but who knows.
  transformed_point.translate(-0.5 * meters, 0, 0); // left = negative X
  transformed_point.roll(60.0 * degrees);

The first thing I want to point out is that it's less lines of code to use. It's a bit more verbose, but I think it's a lot more explicit. There's subtle things in that API too, like that I'm passing three parameters in the scale and transform -- one or two is ambiguous, and with a method name like "scaleX" or "transformX", it's easy to miss.

And now that all the transformations are independent methods, I can inspect the intermediate result without understanding the internals of the API -- if I get a wrong result, I have a clear debug path that's not delving into a metasystem.

Suspicious Dish posted:

It's probably also faster, given that the compiler might be able to inline the calls to simple math methods rather than a generic system.

Suspicious Dish posted:

Note that this isn't a *new* API. I've seen it done a thousand times over, since 1996. There's a reason it's *the* API for this.

Suspicious Dish posted:

"left" is a relative thing. What space is it relative to? Who decides that? The user of the library? Where?

Suspicious Dish posted:

If, for instance, your model format has a different understanding of X/Y/Z than your engine, you can fix that once, on model load. Making something where everything is generic at runtime is a recipe for disaster. Will you generate your vertex shaders with different coordinate systems, too? Will you correct before you do the upload?

That Turkey Story posted:

I agree that that's a real problem at this point in time with the state of C++. I basically pursue this library, and really any other generic library, with the underlying assumption that eventually C++ will actually have direct support for concepts in the language at some point, in which case adapting the library to use those features will instantly mean better error messages.

That Turkey Story posted:

These aren't assumptions, the function works with any compatible coordinate space. It doesn't have to know if the system is left or right handed and it doesn't need to know the relative order of the components. It works in entirely generic code. The order of the parameters should be intuitive to anyone familiar with linear algebra since it's the same order as the abstracted-away matrix and vector operations. You go left-to-right multiplying.

That Turkey Story posted:

I don't see that at all. How is transformed_point.scale(2.0, 4.0, 1); more clear than scale( width = 2.0, height 4.0 )? I don't see how anyone reading the first bit of code would have fewer questions than the second. What dimension does 2 affect, what does 4 affect, etc.

That Turkey Story posted:

The opposite is actually true. In my library you obviously can do the equivalent of what you have shown, spread across separate statements, but I prefer the form presented in my example because it's often more efficient as well as more concise, and it minimizes top-level mutation (in fact, there is none). The reason is that underneath the hood, the different transformations can be combined, simplified, and take advantage of expression templates if the underlying library uses them (I.E. Eigen), etc.

Suspicious Dish posted:

If I have a position vector, what does scaling it twice by height even mean? A position doesn't even have a width or height. You can say "I scale it along the scene-space horizontal axis", but I would call it a stretch to call that width. I'm going to assume that scaling the width means blinding multiplying the X field of the point against the scalar, ignoring rotation, because that's what I would expect a naive point class to do if I called the "scale" function.

Suspicious Dish posted:

Who decides if "height" modifies the Y or the Z vector? Both these systems are in common use, and I don't see anything in your code that decides this.

Suspicious Dish posted:

You can punt and say "well, it can modify the Y or Z axis depending on something at compile time / run time", but that just makes my breakpoint debugging harder. At debug time, I see "x", "y", or "z" fields, and I have no idea what scaling the "height" does in the spur of the moment.

Suspicious Dish posted:

I notice you also left the question of the order of the transformations unresolved. I still don't know what the ordering is, because I haven't read the spoiler text.

Suspicious Dish posted:

The CryTek engine had the same concept of finding inverse transforms and cancelling them out automatically, until they found that simply doing the math would be faster than trying to detect which transforms would cancel, etc. It didn't work out in practice.

That Turkey Story posted:

Okay, this is the kind of feedback I was hoping for, and looking back I guess my comment in the code was poor. What the code is effectively doing is transforming the reference frame.

That Turkey Story posted:

That part is left to person using the library. In your project, you know that your vector's "y" is up or "z" is up. You tell the library this via a tiny bit of compile-time metadata at one spot in code.

That Turkey Story posted:

Read the spoiler text. I think ultimately I need to come up with a better name than "transform" for the operation.

That Turkey Story posted:

If you don't know whether or not y corresponds to "height" in the spur of the moment then you are sharing in my pain.

Suspicious Dish posted:

So you're effectively building a transformation matrix containing those transform operations. Why not have this as two steps — build matrix from these transforms and then multiply it with the point? That's a lot clearer to what this will eventually do.

Suspicious Dish posted:

What's the benefit in keeping it flexible if it's a global piece of metadata? I was imagining that it would be per-point.

Suspicious Dish posted:

I opted not to read the spoiler text intentionally, because the point of the exercise to test my impression of the API without knowing anything. You can certainly keep a method like perform_transform that takes one of these transform operations, but I'd keep each transform as a separate method call. That makes the ordering of the operations clear. Putting the source at the beginning is another choice, as that's fairly clear as well. Having the source at the end causes doubt in my mind.

Suspicious Dish posted:

If I was writing a game engine, I'd know in the spur of the moment because I'd pick one convention and stick with it for the entire engine. X/Y/Z coordinates are not "internals" of a point, they're the very things that a point contain.

That Turkey Story posted:

I think I'd much rather see code like "acceleration[forward] = 5.0 * meters / sec" than "acceleration[2] = -5.0".

That Turkey Story posted:

My only issue with putting the object being transformed first is that that's not the order you'd expect from matrix multiplications, so if you are more familiar with this operation, you'd expect the object to be last. While I want things accessible to people who don't do much linear algebra, I also want things to be intuitive for people that do. My gut says that if I just pick a better name that conveys the importance of order and that the transformations are accumulated, it would make things more clear for both parties, but perhaps not.

Splat posted:

Well, what you put first also depends on if your matrices are row or column major, so it's hard to say what people would expect to be where.

That Turkey Story posted:

The code has the same result regardless of storage order. Accesses of matrices are done internally through named tensor indices.

That Turkey Story posted:

My only issue with putting the object being transformed first is that that's not the order you'd expect from matrix multiplications, so if you are more familiar with this operation, you'd expect the object to be last.

That Turkey Story posted:

Efficiency aside, I just want to make things generic and also eliminate thinking about the matrix side of things for the common types of transformations that people do. In my opinion, it's sort of an embarrassment of the field that in order to make progress with non-trivial game development (or most things graphical) you need to know, at least to some extent, what a homogeneous coordinate system is, what a quaternion is, how to properly accumulate transformations, etc.

h_double posted:

I've been tooling around with HaxePunk a bit and it looks extremely snazzy.

...

It looks like there is also a Haxe Flixel port (HaxeFlixel) if Flixel is your thing.

Splat posted:

I didn't say it would have different results. I'm saying I work in row major stuff all day and you normally end up putting your point on the left, not the right.

Suspicious Dish posted:

You can build simple tools on top of matrices, like "turn left", "turn right", but you can't really expect people to grok 3D graphics without understanding the idea of relative and absolute spaces

Suspicious Dish posted:

That still doesn't answer the question "relative to what". What if I want to have a billboard sprite that always faces the camera? (Still common even today in games, but more cleverly hidden). If your simple API only allows me to specify transforms in the absolute space, I need to step down to the matrix level.

Suspicious Dish posted:

It's an abstraction where you can provide a toy learning API, but not an abstraction that you can skip entirely. Soya3D attempted the same thing and then gave up and added matrices at the API level because it's a needed thing.

That Turkey Story posted:

Okay, I see. I thought you just meant that you were changing storage order, not access. In other words you use row-vectors as opposed to column-vectors, work with the transpose of what I would call a transformation matrix, and order everything the other way around? Is this common? Is this at a company or just an independent project? I think I can understand expecting the reverse order of parameters in that case, though the library still needs to pick one convention since that's all thankfully abstracted away. Whichever order I use, I want that order to be recognizable from the name. You shouldn't have to care about backend details like that at a high level.

aerique posted:

It's been a while but try some float values instead of the integers you're using now, so instead of 15 try for example 15.35. Or just stay between 0 and 1.

From what I recall from perlin noise is that it is made to wrap around so 0 and 1 it will indeed always return 0.

quote:

Is what I did standard practice, just grabbing some random unused semantic and adding extra data to vertices to use for whatever you want in a shader?

Spatial posted:

The proper way is to use uniforms, which you can set by name from your main program.

Orzo posted:

So, uh, it worked pretty well the first try. Is what I did standard practice, just grabbing some random unused semantic and adding extra data to vertices to use for whatever you want in a shader?

Winkle-Daddy posted:

The only thing I'm not really grasping here is, I was under the impression the values I supplied to pnoise2 were the X and Y coordinates, so that I could do something like:

code:

for x in xrange(0,100):
    for y in xrange(0,100):
        object = pnoise2(x,y)
        if(object > .2):
            <instance some tile>
        elif(object < .2):
            <instance something else>
        else: etc

Perhaps I'm not understanding how this module is used, still?

Orzo posted:

I see. Why even confuse things with semantics in the first place, then? What is the point in *requiring* that I label a certain chunk of vertex data 'oh this is a COLOR4' but then using the 4 values for something completely custom?

aerique posted:

I'm not familiar with the module and it has been a couple of years since I have played with perlin noise, perhaps someone more knowledgeable will correct me, but...

pnoise2 is a two-dimensional function: you supply it with two values and it will return a value between -1 and 1:

• pnoise(x1,y1) = z1
  
• pnoise(x2,y2) = z2
  

If x2 and y2 are near x1 and y1 then z2 will be near z1.

The code you posted should work, except I would do the object assignment as such:

code:

object = pnoise2(x/100,y/100)

You can ofcourse offset, rotate and scale the vector with which you move through "perlin noise space", with which I mean you do not have to directly map the X and Y from your world to the input values of the pnoise2 function.

Suspicious Dish posted:

Because history, because there wasn't always such a flexible system and because clever people like yourself developed techniques that worked fine, and there isn't really a need to introduce a new API that loses the specifics when all it will do is break on old systems, and give new churn for everybody to port to.

Doesn't stop the GL people from trying, though.

That Turkey Story posted:

a slime posted:

Hey, I just want to say that what you're doing is really interesting, and I would love to see more generic programming stuff applied to gamedev. Hope you post more stuff in the future.

That Turkey Story posted:

I'm much more used to getting criticized for trying to do generic stuff and use boost or templates in general in game development.

Tres Burritos posted:

Does anyone have any good links on terrain generation they'd like to share?

My cursory googling brings some stuff up, not all of it is wholly readable and not all of it is wholly useful.

I figure I'll start small with 2d maps and then work my way up if that helps narrow it down at all.

That Turkey Story posted:

C++ code:

  auto const transformed_point
    = transform( scale( width = 2.0, height = 4.0 )
               , translation( left = 0.5 * meters )
               , rotation( roll = 60.0 * degrees )
               , position                           // What to transform
               );
}

For example, here it will double the width and quadruple the height, leaving the depth unchanged. It will then translate within that new reference frame (so the translation effectively would go left by 1 meter, not 0.5 meters, which is the main "tricky" part that I'd like to better convey directly within the code).

Just like matrix multiplication, the order is not commutative. If you want the translation to not be affected by the scale, for instance, you do it before the scale parameter.