Wedge

"It's simple math, really" -- now I wonder who said that :lol:

Unlike the maths I'm doing involving creating meshes procedurally, and just for shits 'n' giggles, the way OpenGL works is that you have to declare each face's points clockwise relative to the normal that the face will generate... doing it anticlockwise means the face is (as far as you're concerned) backwards. That ain't simple math.

I remember that! Fucking cool. The tile mesh in Kyodai Mahjongg was made procedurally, too. I never found a satisfying tile mesh with rounded corners, and never got into modeling 3d objects. Hated that.

Be happy that you're not using D3D, as it is WAY less cool as OpenGL. I wish I'd never made the switch.... ahhhhh the memories, so far away...

Technically I'm not directly using either, I'm using Unity which abstracts a bunch of this stuff away. (Though in this case it's being built ultimately for OpenGL ES 2.0, for iPads)

You still have glQuad() though, don't you..?

Ahhhh, glQuad... D3D 1-8 (dunno about later versions) forces you to use only triangles. I never cared for low-level stuff, and D3DX sucked bad (and didn't support quads either, IIRC.)

I don't touch OpenGL directly. Though in theory I could if I wanted to, since Unity Pro (which I have) exposes low level interfaces, but I really don't want to tangle with Objective C at this stage.

Unity 3.x only exposes triangles, Unity 4.x allows for quads as mesh components, but in this case I'm using raw triangles anyway because it makes the maths much simpler for what I'm doing (seeing that I'm dealing with objects with actually-triangular faces for the most part). There's a hell of a lot of stuff Unity abstracts away - bear in mind that I have the exact same code and same project running on Windows, OS X and iOS with only one change (which operating system is selected at the time) because Unity hides that stuff away.

What exactly are you using C# and Unity for, Pete..? A game project with Louis, I'm guessing?
Is this related to your pre-Wedge project (on the occasion of which, IIRC, you met him), or is something new?
Is it made out of a desire to have a side-project alongside Wedge, or to simply find a realistic source of revenue?

And why didn't you discuss it with me, like ever..? I have no problem with not being offered to join the project of course, but I'm an Hejlsberg follower myself, and I have experience with 3D programming, as I'm sure you remember by now... ;)

Yes, making a game in Unity.Yes. The company was formed last year. Up until now it's been largely doing SQL database stuff, which I've only been involved in sporadically. The plan was always to break out and do other stuff. Part of this trip was to get into writing with Unity so that we could go make some of the many games we've discussed.A little of both. I've never considered Wedge on its own as viable revenue for a full time job; I just don't believe - as I've said - that the market is big enough to support another paid project to support full time development. There are also questions I've raised as to quality (not that I consider there to be a quality problem, because there isn't, but in the minds of customers there could be because of somewhat misguided views on how things 'should' be)

As I've said elsewhere too, my own plan for plugin monetising, the plan from my perspective ultimately was to have it be able to cover server costs and anything extra would be nice pocket money.I hadn't forgotten your 3D programming experience at all. However... Unity doesn't expose the normal 3D interface. It's heavily abstracted such that you never touch OpenGL or DirectX directly - remember that the same project cross compiles to Windows, OS X, Linux, iOS (with a Unity plugin), Android (with a Unity plugin), and if you have the appropriate licences even for PS3, XBox 360 and Wii. That's how abstracted it is.

For example, here's the core of the stuff I'm doing right now, in terms of procedurally generating meshes - http://docs.unity3d.com/Documentation/ScriptReference/Mesh.html

It really doesn't help that Unity supports 3 separate languages, Boo, JavaScript and C#... JS is run at runtime through a mostly-JIT compiler, while C# is compiled ahead of time which means you have an advantage in terms of speed... and you can intermix the two quite happily provided the order of compilation isn't a problem (i.e. you're not trying to call code that hasn't been compiled yet)

And once you get into Unity itself, there's an awful lot of architecture around which to implement things. Most developers in Unity will never even procedurally generate meshes but simply use models. A surprising number of Unity devs use it for easy cross-platform 2D development, too.

Honestly, it was simply the fact that it's a long way away from the world of 3D programming you've done before and there's a huge learning curve to deal with. As I've said, C# is a largely different world to PHP and especially inside Unity... it's pretty nice in the way it's prompted me to rethink about programming. Honestly, I'd love to be able to architect Wedge plugins the way I can add components to things in Unity but that isn't ever going to happen (each GameObject has one or more components that can all interact with the GameObject, or indeed any object currently in the scene). Then of course you start to realise you can do things like having multiple cameras, and even rendering a camera's view to a texture so you can do things like the huge video displays in a sports game.

In all the stuff I've done with Unity to date, the only reason I'm not using modelling for these objects is because I'm creating mathematically accurate models (the platonic solids) and then plugging in an expansion I have to create vector-like lines around the edges, to represent something in the display in the game. If it were anything else we'd have broken out the modelling tools and imported meshes/textures/rigging/whatever rather than doing it programmatically.