Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / AGK 2 Official Development Blog

Author
Message
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 25th May 2015 23:37
Well, I would want to use the existing sprite system and all of those great capabilities so I am thinking the collisions would not take into account the Z-Axis. If a sprite overlaps a 3d object (irregardless of it's Z position) then that would be a collision just like any other sprite to sprite collision.

I love my Altair 8800 Replica.

http://altairclone.com/
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 26th May 2015 09:27
Try ray casting from sprite position on screen into z-axis?

Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 28th May 2015 20:18 Edited at: 28th May 2015 20:19
I don't see how that would work using current commands.. could you post an example?

I love my Altair 8800 Replica.

http://altairclone.com/
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 28th May 2015 20:39
It wouldn't work for a couple of reasons:

Depth changes position. So a 3D object 1 metre away in 3D space has a different X/Y 2D position to a 3D object on the same Z coordinate 500 metres away

You would have to ray cast every pixel on the 2D sprite.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 29th May 2015 09:22 Edited at: 29th May 2015 09:33
So the reason I ask is back when I used Blitz, I wrote a side-scrolling shooter that used 3D objects. In Blitz you could set the camera FOV so that all 3D objects appeared flat so you would only see one "straight on" perspective no matter where in 3D space it was positioned. The great thing about this that you could turn and animate 3d objects and they would appear as animated sprites but without having to use a bunch of sprite sheets. It actually worked exceptionally well and it would be nice to be able to have that available in AGK. Especially that linepick (a raycast that returns the first object from x,y,z to x,y,z) command, that worked really well for a number of things... especially effective in this scenerio if you kept all 3d objects on the same z-axis.

As I said, aside from this example, I think it would be really helpful to include commands that allow sprites and 3D objects to interact through a collision detection system because some things like bullets for example I think are better handled by sprites. Coupled with flat camera projection, I think this would open up a lot of new possibilities.

I love my Altair 8800 Replica.

http://altairclone.com/
fog
20
Years of Service
User Offline
Joined: 5th Oct 2003
Location: Newcastle, England
Posted: 29th May 2015 09:41
I haven't dabbled in 3d so pinch of salt and all that...

Couldn't you create dummy sprites for your game objects, position them as required, add collision shapes, physics etc. and then use Get3DVectorXFromScreen() etc to position your 3D models at the location of the dummy sprites?

Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 29th May 2015 10:57 Edited at: 29th May 2015 11:05
Well, I don't think you could get the collision shapes to match the 3D objects in a practical way. For example, in my game you are flying a plane, when you push the control pad in the opposite direction, the plane would loop around so you would see the top of the plane (and all the incremental turning) as it did a loop to face the opposite direction of where it started... not to mention a propeller turning this whole time. It would be a *lot* of work to try and do something like this with sprites, too many angles of movement going on but dead easy with this flat camera system and a 3D object, just a bit of maths to figure out. A little hard to explain though...

I might dust off that old BB3D code and do a video capture to show you guys a practical example.

I love my Altair 8800 Replica.

http://altairclone.com/
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 29th May 2015 11:30
From what you are describing, it sounds to me like you are writing a 2D side scrolling game using 3D objects. If so, then instead of using sprites and trying to use some complex maths or a vast amount of raycasts, then why not simply use flat plains with your sprite images on them?
They would occupy the same 3D world space and sit on the same Z axis making everything you are trying to achieve really quite simple.

AGK V2 user - Tier 1 (mostly)
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 29th May 2015 15:55
I think the problem is being looked at back to front, as Scraggle has just identified. It is easier to put a 2D concept into the 3D world, than it is to do it the other way.

3D Plains (2-dimensional) for sideways collisions, and raycasting for picking screen coordinates.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 30th May 2015 08:19 Edited at: 30th May 2015 13:22
Ok, so unless I am completely wrong about how sprites work...

What you guys are saying is to attach another 3d flat plane to what is already, internally a flat 3d textured plane masquerading as a "sprite". I am saying it is already a flat 3d plane so adding commands to allow these to interact with other 3d objects... and maybe the trade-off is that for sprite-to-object collision to work, the 3d objects would have to be on a zero z-axis (or whatever z-axis the sprites are on) where the sprites reside. As I have found with B3D, being able to use 3d objects essentially as 2D Sprites (along with flat camera projection) would open up a lot of new possibilities for AGK.

Now if sprites aren't actually handled this way for whatever reason then disregard everything I just said.

I love my Altair 8800 Replica.

http://altairclone.com/
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 30th May 2015 17:51
Quote: "What you guys are saying is to attach another 3d flat plane to what is already, internally a flat 3d textured plane masquerading as a "sprite""


No, forget the 2D sprite. Replace it with a 3D plane. There are some simple equations out there to convert a 2D screen position to a 3D Plane position so that it looks identical. These equations will also help to position your other 3D objects to look like a 2D game.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 30th May 2015 21:46 Edited at: 30th May 2015 21:48
I know you are trying to be helpful and I appreciate that but I am not looking for a half-assed workaround... I do not want to give up the sprite physics, collision shapes, animation, etc (think I mentioned this already). We could go on talking about ways this could "sort of kinda like" be done in the current system ad naseum but I can't think of a single reason not to add a couple of sprite to object collision commands. I do not understand why sprites and 3d objects have to be segregated. I don't believe there is any benefit in doing that.

Also, you really can't get the correct 3D-to-2D effect if there is no flat camera projection because as the objects are positioned above, below, left, and right of the camera, the perspective view kicks in and you can see their depth which is exactly what you don't want in this concept... the whole point is that 3D objects look like a traditional 2D sprite but can rotate in 3 dimensions and animate like 3d objects. Case in point, if I have a turret on the ground that I want to rotate 360 degrees, that would require 360 animation frames for a 2D sprite - OR- I could use one small animated 3d object and have a quick, easy way to test if my bullet sprites have collided with it. Pretty simple idea really.

I love my Altair 8800 Replica.

http://altairclone.com/
gwheycs62egydws
14
Years of Service
User Offline
Joined: 17th Aug 2009
Location: The World
Posted: 30th May 2015 21:54
@Alien Menace

i understand what your going on this thought

3d and 2d talk to each other and saves having to make a lot of
sprites and give back speed to the item being made
with less resources being needed

I'm personally not into 2d games any more but
i can see ware this could be used to mess people up
visually ;o)

to move side ways - is to move forward
Since a Strait line gets thin fast
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 31st May 2015 01:13
It's the eve of the second half of the year.
Any chance of getting any hints for 3D commands progress?
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 31st May 2015 03:58
Quote: "I know you are trying to be helpful and I appreciate that but I am not looking for a half-assed workaround..."


I don't believe it was meant to be a "half-assed workaround". It was meant to be a genuine solution.

Quote: "I can't think of a single reason not to add a couple of sprite to object collision commands. I do not understand why sprites and 3d objects have to be segregated. I don't believe there is any benefit in doing that."


The systems that detect 2D collisions are inherently not 3D. To give you an idea of how complicated this actually is... First: Are you looking for physics collisions (i.e. a sprite bouncing off a 3D sphere) or just collision detection (i.e. if(spriteIsOver(sphereObject)==true))? And then there's the question of whether you want the collision to be detected when the sprite is visibly "over" the 3D object regardless of depth or... I don't even know what else.

How do you actually expect these commands to work?

Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 1st Jun 2015 04:23 Edited at: 1st Jun 2015 04:36
Quote: "I don't believe it was meant to be a "half-assed workaround". It was meant to be a genuine solution."


Well obviously just texturing a flat plane would not accomplish the desire to keep the retain the sprite's functionality (which you can read further up) intact, which means the solution BatVink provided would only accomplish part of what I have been talking about. I did not mean to offend anyone (sorry BatVink if I did, not my intention) but at the end of the day, it is what it is.

Quote: "The systems that detect 2D collisions are inherently not 3D."


Not so sure about that. I didn't write it, so I can't say for sure how AppGameKit works internally but my best logical guess is that AppGameKit collisions use box2D raycasting whether you are using physics or not...3d but on a 2d axis. They share the same collision shapes anyway. The fact you can use shaders on sprites, set alpha, set the color, and change the UV of the texture... I mean sprite image would also lead me to believe that sprites do exist in 3d space as textured planes but are confined on their z-axis (as I have already surmised above). This is just my best guess, if one of the programmers from TGC who knows for sure would like to set the record straight then that would be great, until then I will stick by this assertion, just thinking logically here and trying to put 2 and 2 together.

Quote: "To give you an idea of how complicated this actually is... First: Are you looking for physics collisions (i.e. a sprite bouncing off a 3D sphere) or just collision detection (i.e. if(spriteIsOver(sphereObject)==true))? And then there's the question of whether you want the collision to be detected when the sprite is visibly "over" the 3D object regardless of depth or... I don't even know what else."


So first I was thinking about something like:

integer GetSpriteCollision3DObject ( iSprite1, iObject1 )

So that would just give a detection if the sprite's shape collision makes contact with a 3d object's shape but you are right, doing that brings up a number of questions... and some actually pretty good ones at that. So you would have this problem for sure.. 2d sprites use a physics system based on box2d, the 3d system is suppose to eventually suppose bullet physics which I think would be nightmare to try and get them to work together and even if you could figure that out, you would always have to constrain the objects z-axis which would create presentation problems with the 3d object.

So as I am reading about this and giving it some more thought, since the whole idea resolves around a a couple of ideas..

1. Being able to use a 3D object in a 2D game to gain the benefit of the rotation and animation of a 3d object.

2. Maintaining the abilities of the 2D sprites including box2d physics.

3. Present the 3d object as a flat 2d-style sprite.

4. Detect collisions between 2d sprites and 3d objects.

So, after pondering this list for a while I am thinking there may be a different way to accomplish all these things. Why not provide a command to turn the 3d object into a 2d sprite?

SetObjectAsSprite ( iSpriteIndex1, iObjectID1 )

This would basically create a 2D sprite that would be textured with a flat 3d object and would be animated and rotated in 3d space using object's commands instead of a spritesheet but it would otherwise be treated as a sprite for the purposes of depth, collision detection, physics, movement, etc.

Also, using the command:

CloneSprite( iSpriteIndex1, iSpriteIndex2 )

Would clone the sprite (iSpriteID2) and would be textured with the exact same animation and rotation as iSpriteID1. To animate and rotate the same sprite object independently, you would just do this:

CloneObject( newobjID, objID )
SetObjectAsSprite ( iSpriteIndex1, newobjID )

I think this solves the issue by my reckoning anyway to achieve super smooth animation and rotation without having to use a ton of sprite sheets and would not require your whole scene to be rendered flat so you could still have background objects with depth.

Quote: "How do you actually expect these commands to work?"


Does this answer your question? I think I need a nap.

I love my Altair 8800 Replica.

http://altairclone.com/
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 1st Jun 2015 06:57 Edited at: 2nd Jun 2015 00:36
Here's a quick demo of using a flattened 3D object as a sprite...



This was done in Blitz3D, no sprite sheets, no pre-rendered animations, only the 2D backdrop and a 68kb animated model and a 107kb texture.

I love my Altair 8800 Replica.

http://altairclone.com/
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 1st Jun 2015 10:31 Edited at: 1st Jun 2015 10:33
Quote: "I did not mean to offend anyone (sorry BatVink if I did, not my intention) but at the end of the day, it is what it is."


Good, good That's all I wanted to hear

Quote: "Not so sure about that. I didn't write it, so I can't say for sure how AppGameKit works internally but my best logical guess is that AppGameKit collisions use box2D raycasting whether you are using physics or not...3d but on a 2d axis. They share the same collision shapes anyway."


Ok, so yes, a 2D sprite is technically rendered with the 3D rendering pipeline. This has been the case since about DirectX7 (or was it DX6?) where dedicated 2D rendering of Direct2D was removed (even though AppGameKit uses OpenGL, the timeline is approximately the same AFAIK). However this is where the similarities end between 2D and 3D.

Quote: "2d sprites use a physics system based on box2d, the 3d system is suppose to eventually suppose bullet physics which I think would be nightmare to try and get them to work together and even if you could figure that out, you would always have to constrain the objects z-axis which would create presentation problems with the 3d object."


Yes. For all intents and purposes you can assume that it's impossible to make two different physics engines work together.

Quote: "This would basically create a 2D sprite that would be textured with a flat 3d object and would be animated and rotated in 3d space using object's commands instead of a spritesheet but it would otherwise be treated as a sprite for the purposes of depth, collision detection, physics, movement, etc."


Now you're talking! However there's still problems with that idea. First and foremost is that you then have to create actual 3D models for all your sprites. One of the advantages and attractions of making a 2D game is the simplicity of creating sprites.

What you really need is per-3D-object orthographic rendering. It's possible AppGameKit already supports this - I haven't looked. Then you would simply load and texture your models, set them to render as orthographic and move and animate them using the standard 3D commands. Your background would have depth because it would still be rendering with perspective but your "sprites" would appear totally flat. You could then have your "sprites" move and interact using the 3D collision/physics system.

Given AppGameKit supports shaders I'd say you could probably write a shader to render the object with orthographic projection pretty easily

Quote: "Does this answer your question? I think I need a nap."


Basically, yeah. Hopefully you have a better understanding of the difficulties involved in mixing 2D and 3D like this. I also hope I've managed to give you some ideas as to how to achieve your goal

Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 1st Jun 2015 11:52 Edited at: 1st Jun 2015 12:00
Quote: "However there's still problems with that idea. First and foremost is that you then have to create actual 3D models for all your sprites. One of the advantages and attractions of making a 2D game is the simplicity of creating sprites.."


Okay, to be clear.. the current sprite system lives on unchanged. This would be additional functionality so no, you don't have to create 3d models for all your sprites unless you wanted to. I am a pretty decent artists and I have not found creating 2d sprites particularly easy, especially ones with complex animations. In fact I find the process tedious and is probably one of the bigger reasons I lag on finishing a project. Also, TGC sells model packs, you could buy and sell them on TGC's upcoming AppGameKit store.

Check out the horse animation I posted above... how many sprites images would that have taken to accomplish do you think?

Quote: "What you really need is per-3D-object orthographic rendering. It's possible AppGameKit already supports this - I haven't looked. Then you would simply load and texture your models, set them to render as orthographic and move and animate them using the standard 3D commands. Your background would have depth because it would still be rendering with perspective but your "sprites" would appear totally flat. You could then have your "sprites" move and interact using the 3D collision/physics system."


Yes, I thought about that too but that doesn't really accomplish any more that BatVink's suggestion. This would work find if we were only using 3d flat objects but that's not the plan, the plan is to be able to mix 2d sprites and 3d objects and check for collisions between them. Integrating the 3d model into the 2d sprite system as I suggested would also give you access to box2d physics for the 3d object sprites and the standard collision system which would make things very easy to use, and more importantly I think it would actually work and work well.

I mean load the mesh, assign it to a sprite and viola... it's a sprite. Move it like a sprite but animate and rotate it using the mesh animation and rotation commands. If such a thing existed, it would be dead easy to use.

Quote: "Hopefully you have a better understanding of the difficulties involved in mixing 2D and 3D like this. I also hope I've managed to give you some ideas as to how to achieve your goal"


I think there has been a little confusion. I have never asked how to accomplish this within AGK2 today and believe me, after writing over 2 dozen games in AppGameKit, I have a clear understanding of how to texture a plane and use it like a sprite. That's not what I am after. I am also not out to solve this problem using what is currently in AGK2 even if there are some workarounds that may partially solve the problem.

What I did want to accomplish is to figure out how mixing 2D sprites and flat 3D objects could work as a complete solution and I think I finally figured it out (thanks to a lot of input from people along the way). The way of going about it has definitely evolved during the course of this thread. At the end of the day, I am asking for consideration of 1 command:

SetObjectAsSprite ( iSpriteIndex1, iObjectID1 )

By my reckoning, this is game creation language and you should want capabilities like this. If we love this language we should start thinking out of the box a little to give AppGameKit an advantage over it's competitors and the capability to enhance our games when it makes sense to use it. Maybe it doesn't make sense in every scenario.. so what? Neither do 3D graphics, physics, etc. but they are there to use if you need them.

I love my Altair 8800 Replica.

http://altairclone.com/
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 1st Jun 2015 11:58 Edited at: 1st Jun 2015 11:59
SetRenderToImage( colorImage, depthImage )

You then have an image rendered from your 3D object.
Use that to assign to your sprite.

AGK V2 user - Tier 1 (mostly)
Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 1st Jun 2015 12:06
If I read this right, I think this renders the entire screen to an image not just a particular object. I think, I dunno.. that description gave me a headache about half way through... kind of like when i go back and read my own posts.

I love my Altair 8800 Replica.

http://altairclone.com/
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 1st Jun 2015 14:50
Here you go. Attached project shows a rotating 3D Asteroid (centre), and a rotating 2D Sprite Asteroid (left).

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt

Attachments

Login to view attachments
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 1st Jun 2015 16:01 Edited at: 1st Jun 2015 16:57
@Batvink,

That's really cool - however I'm not sure how many objects you could use that process on, GetImage is really slow and I suspect it would rule out most mobile platforms right away at decent frame rates.

On a side note......can I "borrow" that model? lol.

EDIT: forgot to say also, get image doesn't work with alpha transparency either, it makes them solid. That's why I used membkocks instead, but that wouldn't work for this.
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 1st Jun 2015 18:43
I didn't put too much thought into it, it's just a proof of concept. It would need a lot more work, probably involving a more efficient shader.

I got the asteroids from here.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
RickV
TGC Development Director
24
Years of Service
User Offline
Joined: 27th Apr 2000
Location: United Kingdom
Posted: 3rd Jun 2015 13:39
Hi,

I have updated the blog post with the latest news.

Rick

Development Director
TGC Team
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 3rd Jun 2015 13:53 Edited at: 3rd Jun 2015 13:58
Quote: "Yes, I thought about that too but that doesn't really accomplish any more that BatVink's suggestion. This would work find if we were only using 3d flat objects but that's not the plan, the plan is to be able to mix 2d sprites and 3d objects and check for collisions between them. Integrating the 3d model into the 2d sprite system as I suggested would also give you access to box2d physics for the 3d object sprites and the standard collision system which would make things very easy to use, and more importantly I think it would actually work and work well."


Yeah but you can't directly mix 2D and 3D and that's what I've been trying to say. You need to have some intermediate device to allow the two systems to communicate. Obviously that's what you're asking TGC to add, but there are major issues. For example...

Quote: "I mean load the mesh, assign it to a sprite and viola... it's a sprite. Move it like a sprite but animate and rotate it using the mesh animation and rotation commands. If such a thing existed, it would be dead easy to use."


...what shape would the mesh be? What is the mesh for if the sprite is still used? If the mesh is intended to be a collision object, what if the sprite is animated? Would you animate the invisible collision mesh to match the sprite's animation?

As far as I can see (and of course I may have missed something obvious), you still have yet to come up with a genuine solution to your problem.

Quote: "Work has started on the 3D and physics systems for AppGameKit."


Excellent, excellent! Can't wait!

yamyam
11
Years of Service
User Offline
Joined: 12th Jan 2013
Location: Black Country
Posted: 3rd Jun 2015 15:07
Quote: "Development Update
3rd June 2015
Work has started on the 3D and physics systems for AppGameKit. Currently the work has been research based to establish how best to move forward. We're aiming to support the Collada 3D file format. AppGameKit now has an XML importer so we're able to read the Collada file structure. The next phase is loading in the geometry data into an AppGameKit object. We have exported an animated soldier from our Game Guru project and will use this as a test model for the first iteration. We've also been playing around with the Bullet Physics source code and have the examples compiling and running. There has been no integration yet with AppGameKit."


Great news on the bullet physics, being one of the kickstarter funders that helped push it through this goal, we users that went that extra mile may now see work in this area. And looking at the competition, cost and availability of 3d physics this will benefit TGC also. Many ideas in the pipline for the physics engine Like multiplayer Jenga, coin roll, coin dozer etc. cant wait keep up the good work Paul J


Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 4th Jun 2015 06:03 Edited at: 4th Jun 2015 06:15
Quote: "Yeah but you can't directly mix 2D and 3D and that's what I've been trying to say. You need to have some intermediate device to allow the two systems to communicate. Obviously that's what you're asking TGC to add, but there are major issues. For example..."


If you go back and read you may see I abandoned this idea some time ago, mostly due to the objections you brought up. Forget about mixing 2D and 3D, just forget it. Too many problems with that. What I finally proposed is using a flat rendered 3d object as a texture for a sprite instead of an image... capiche? Very similar to BatVink's demo above but it would be an internal command to accomplish this and would not need to have the 3d object to be onscreen to be GetImaged. (Thanks for the demo Bat.)

Here, allow me to save you some time and I will quote myself:

Quote: "SetObjectAsSprite ( iSpriteIndex1, iObjectID1 )

This would basically create a 2D sprite that would be textured with a flat 3d object and would be animated and rotated in 3d space using object's commands instead of a spritesheet but it would otherwise be treated as a sprite for the purposes of depth, collision detection, physics, movement, etc."


So to clarify, basically using this command would take a loaded 3d object and make it into a flat 2d sprite. Period. You can still use animation and rotation commands on the 3d object and those changes will be reflected on the 2D sprite's texture that you have associated with that model using the above command. Look at my horse animation, that illustrates the concept behind this idea of applying 3d animation (horse walking) and 3d rotation (horse turning) applied to a 2d sprite. I would like to reiterate that the horse animation uses no images or sprite sheets for the horse, yet it appears as a fully animated 2d sprite.

Quote: "...what shape would the mesh be? What is the mesh for if the sprite is still used? If the mesh is intended to be a collision object, what if the sprite is animated? Would you animate the invisible collision mesh to match the sprite's animation?"


None of this is applicable, it's not really a 3d object anymore but a texture applied to a 2d sprite. It would use box2d commands for collision, physics, etc. as it is a sprite.

Quote: "As far as I can see (and of course I may have missed something obvious)"


By the points you are still bringing up, I am not sure you grasping the new concept yet of 3d object to sprite.

Quote: "you still have yet to come up with a genuine solution to your problem."


I don't think I actually presented this as a problem in the first place but as a feature request. But if you want to go that route then seeing as how I am probably a better judge than you of whether this idea actually solves my "problem" then I will say I believe it does.

I love my Altair 8800 Replica.

http://altairclone.com/
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 4th Jun 2015 06:34
I hope I am not the only person growing tired of this sprite debate... Please go get a thread for that debate...

I for one have been looking forward to the 3D and Physics additions to AGK... Been waiting some time for it frankly...

Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 4th Jun 2015 09:40 Edited at: 4th Jun 2015 09:46
Quote: "I hope I am not the only person growing tired of this sprite debate... Please go get a thread for that debate..."


Is it a debate? I thought we were having a friendly conversation to pass the time while there is nothing much new on the development front to talk about. Anyhow though, please feel free to set the new topic..

Quote: "I for one have been looking forward to the 3D and Physics additions to AGK... Been waiting some time for it frankly..."


Yep, you, me and everyone else.

I love my Altair 8800 Replica.

http://altairclone.com/
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 4th Jun 2015 10:22
Quote: "the horse animation uses no images or sprite sheets for the horse, yet it appears as a fully animated 2d sprite."


Seems like a clever way of using 3d to creat sprites with less resources and without the hasle of a sprie sheet.
Native commands for this would be good because it would speed up the process for mobile work.

Quite looking forward to seeing what 3d stuff is going to come out.

The Amiga and Amos were great!
Download my game - Paint Pot from Amazon and Google here - http://leap.my-free.website/
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 4th Jun 2015 10:45
Quote: "...would not need to have the 3d object to be onscreen to be GetImaged."


You can put the images off-screen and still grab them. But as already mentioned, it's probably too intensive a process to do on a large scale. By large scale, I mean numbers of objects. I've converted the entire screen before at 60FPS but this was a much simpler process.

But we have geniuses (genii?) on this forum who may have a way of doing it efficiently with shaders or some other wizardry. I see a lot of good uses for this, especially if you can convert the collision parameters at the same time.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 4th Jun 2015 11:03
@batvink,

Can you grab an image that's off screen? I've never managed to get this working, anything off screen simply isn't grabbed. Am I wrong in thinking that the render command does just that - renders a screen space in memory, which is then grabbed, therefor anything off of it is not?
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 4th Jun 2015 15:24 Edited at: 4th Jun 2015 15:25
There are two problems with "grabbing" that spring to mind. The first has already been mentioned and that is the inherit speed loss. The second issue is what to grab. There is no way to grab a 3D object alone. The current commands will grab the background too. So unless you want a square sprite this isn't really going to work for you.

Maybe (I haven't tried) you could use RenderToImage instead and render both the image and a depth buffer. Then you could write a shader that will not render anything from the image that is beyond a given distance in the depth buffer. Of course, you would have to render each image that you want to capture separately or you would be rendering the entire scene - not good.
That sounds in principle like it would work but I don't know if it would solve the speed issue.

If it does work and it works fast enough then I agree with your very first comment: It would be great to have this as a native command

AGK V2 user - Tier 1 (mostly)
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 4th Jun 2015 15:44
Quote: "Can you grab an image that's off screen?"

Quote: "There is no way to grab a 3D object alone. The current commands will grab the background too"


I used this method to make bingo balls. The way I did it was:

1. Place object to grab off-camera (e.g -1000,0)
2. Set the view offset
3. Grab
4. reset the view offset

There is no Syncing happening, just Render()
The resulting sprite is just the object you want to grab, no background interference.

Still, the speed problem persists.

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 4th Jun 2015 15:46
Quote: "The resulting sprite is just the object you want to grab, no background interference"


That's surprising - but useful

AGK V2 user - Tier 1 (mostly)
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 5th Jun 2015 17:01
Quote: "So to clarify, basically using this command would take a loaded 3d object and make it into a flat 2d sprite. Period. You can still use animation and rotation commands on the 3d object and those changes will be reflected on the 2D sprite's texture that you have associated with that model using the above command. Look at my horse animation, that illustrates the concept behind this idea of applying 3d animation (horse walking) and 3d rotation (horse turning) applied to a 2d sprite. I would like to reiterate that the horse animation uses no images or sprite sheets for the horse, yet it appears as a fully animated 2d sprite."


Oh! I think I finally understand what you're getting at! I'm too confused from previous posts to be able to work out in my mind if this would help with collisions, though

Alien Menace
AGK Developer
19
Years of Service
User Offline
Joined: 11th Jan 2005
Location: Earth (just visiting)
Posted: 6th Jun 2015 02:00 Edited at: 6th Jun 2015 03:53
Quote: "Oh! I think I finally understand what you're getting at! I'm too confused from previous posts to be able to work out in my mind if this would help with collisions, though"


Yeah, understandable. Collisions would just be the standard 2d sprite box, circle, polygon. Just keep in mind that this would no longer be a real 3d object in the system but is instead providing the image for a sprite. Animate the "object" and the sprite's image animates. Turn the "object" and the sprite's image animates but the original 3d object only resides in memory, no longer appears on the screen. It has been replaced by a sprite that looks like a flat projection of the original 3d object.

I feel strongly there is a need for this, after all TGC released two 3d model to sprite sheet converter tools. This would accomplish the same thing but you would get all the animations, every degree of rotation on all 3 axis, with no sprite sheets.

Thinking of that though, TGC might not be keen to add something like this because it would probably make these two tools they sell obsolete. Hmm, hadn't thought of that until now.

I love my Altair 8800 Replica.

http://altairclone.com/
Clonkex
Forum Vice President
13
Years of Service
User Offline
Joined: 20th May 2010
Location: Northern Tablelands, NSW, Australia
Posted: 6th Jun 2015 04:42
Quote: "Thinking of that though, TGC might not be keen to add something like this because it would probably make these two tools they sell obsolete. Hmm, hadn't thought of that until now."


I doubt that would affect their decision. AFAIK they didn't develop the tools themselves (they sometimes do business deals with people that have developed tools related to one of their products).

PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 8th Jun 2015 17:42
RickV wrote: "AppGameKit now has an XML importer so we're able to read the Collada file structure."


Does that mean Tier 1 is getting native XML support?
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 8th Jun 2015 17:50
Quote: "Hi, in the spirit of openness and transparency we're now publishing the daily progress of App Game Kit 2 Development. For now we'll post into this message, longer term we'll setup a proper Blog on the main AppGameKit site."


Where are these daily updates?
They aren't in this thread so I presume the 'proper blog' has been set up.
Could someone please provide a link?

Thanks.

AGK V2 user - Tier 1 (mostly)
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 8th Jun 2015 18:39
Hi Scraggle. As far as I know there never was a blog set up on the main AppGameKit website, and this thread is all there is.
Impetus73
12
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 9th Jun 2015 14:45
It's in the first post in this thread, go to page 1, and look at the top, he adds to the one there.

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 9th Jun 2015 14:53
Daily progress.

There are no daily updates in this thread. First post or otherwise.

AGK V2 user - Tier 1 (mostly)
Rais
20
Years of Service
User Offline
Joined: 7th Jul 2003
Location:
Posted: 9th Jun 2015 15:45
No updates on Steam either
Jambo B
14
Years of Service
User Offline
Joined: 17th Sep 2009
Location: The Pit
Posted: 9th Jun 2015 20:01
I'm interested to see that we'll be able to read in Collada-type (.dae) models. Does this mean that models created in Mixamo will be able to be used right out of the box? Here's hoping!

James
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 11th Jun 2015 02:27
It could be great to be full compatible with animation tools yes ...

I also hope we will have the ability to manipulate vertices directly... i have worked on a B3D Loader with lightmaps (T1) but i can't deal with B3D File Animations sections (vertices manipulations required !) :p

But for static scenes it's ok



--------------
RickV
TGC Development Director
24
Years of Service
User Offline
Joined: 27th Apr 2000
Location: United Kingdom
Posted: 11th Jun 2015 10:39
Hi all,

Daily updates is not going to be possible during the main 3D development work. Paul is essentially locked away working on it. Once he has something to show then we'll bring it to your eyes. I'm sure you'll appreciate he has a lot to get on with. I will aim to update the blogs every couple of weeks even if nothing visual can be shown.

Rick

Development Director
TGC Team
gwheycs62egydws
14
Years of Service
User Offline
Joined: 17th Aug 2009
Location: The World
Posted: 11th Jun 2015 19:31
we all wish to know ware things are at
but with there so much work to be dun
they will post when they achieve that objective

get the basis worked out first
then add in as they can

the one thing i am glad as far as i have seen
the code for AppGameKit 2 - Tier 1 as in not the high end and confusing programing is like DBP

now that i put DBP back in

i can program in agk2 and copy over the code to
DBP and show what i want it to look like down the road
once the rest of the 3d command and plugin's come into place

to move side ways - is to move forward
Since a Strait line gets thin fast
JulesD
19
Years of Service
User Offline
Joined: 7th Feb 2005
Location:
Posted: 11th Jun 2015 19:57
Please have FBX support, I think collada is a dying format, and I believe FBX is more popular and now free.

Login to post a reply

Server time is: 2024-05-02 19:09:25
Your offset time is: 2024-05-02 19:09:25