One issue simplified. After the release of the latest patch I noticed my non-modular DG room now displays proper textures as opposed to the muddy result I got in earlier tests. One-piece (DG) rooms are back on the menu!

Nihthasu7 wrote:One issue simplified. After the release of the latest patch I noticed my non-modular DG room now displays proper textures as opposed to the muddy result I got in earlier tests. One-piece (DG) rooms are back on the menu!

This might not be the exact place for this... but did any of you guys get a "there are updates available" message when you logged into Spore yesterday? I didn't get the stuff yet, but is it possible they've released a patch of the patch? lol I just couldn't find anything about it on the SporeDay page, or find any notes.

Anyhow, sorry... resume!

iiiHuman wrote:

Hey DVDMaster, I have a question for you.

I don't know if you have figured this out already or if you'd need to test it ( I'm too lazy to test it myself ) but what would happen if you tried the following couple of configurations?





I know that "A" and "B" should ( ) both be able to see each other in either case and "C" and "D" should ( ) also both be able to see each other in either case. But, can "A/B" see "C/D" in either case?

It shouldn't make any difference because none of the blocks are taller than the characters. The bounding box is a box that encloses all the parts of a building and when you draw a box around the blocks, characters a,b,c,d, all end up outside the box.

iiiHuman wrote:Edit: Also, I can't understand why they can't just make the bounding boxes of items equal to (or, actually slightly larger by a pixel or two) than the item. For instance, creatures can partially enter objects you use for walls. Is that mainly related to the creature itself or to the wall object? While it seems that the bounding area for creature visibility runs the full length of objects, the bounding portion of that object is less than what appears for the image of that object. Therefore, you can partially walk into a wall (and get stuck between walls because of it etc). To try and explain better, imagine a box inside another box. The outer box would be the image of the wall itself while the inner box would be the actual bounding area. Why not make them equal? I can understand the bounding box not being larger (or "too much" larger) because then you'll have floating characters but why not at least "equal?" Right now, seems they're not even all that close in size to each other.

There are two separate things here.

First is visibility -- can NPC1 see NPC2? The visibility is used for AI purposes. This is determine by drawing a line between the heads of NPC1 and the NPC2 and see if that line can go from NPC1 to NPC2 without passing through the visibility bounding box. The visibility bounding box is a single box that encloses all the parts of the building. At every tick of clock, the computer has to determine the visibility between every possible pair of NPCs -- and then has to see if the line of sight intersects each of the bounding boxes. If the programmers decided to check visibility using each of the component pieces in a building, there would probably be many more calculations.

The developers might be able to improve this by using multiple visibility boxes per bulding, but not one per part. Maybe by sorting by size or part type, they can add a few more boxes per building that gives a better result.

The second issue is collisions -- where does the character bump into the object. Collisions use the geometry of the actual pieces instead of a single bounding box for the entire building. And as you noted, it is separate from the visual skin of the building. Part of the reason that the skin is different from the collision surfaces is that the skin is generated by the GPU in the graphics card and the collsion surfaces are generated by the CPU. The collision calculations are done using a simple model -- here is a cube with these dimensions. What is sent to the GPU is more complicated -- here is a cube with these dimensions, with a certain thickness, with rounded corners with radius X, using this texture. The GPU takes that information and calculates all the surfaces needed to display it on the screen. The results of the GPU calculations cannot be sent back to the CPU to be used in collision detection and doing all those calculations with the CPU would slow things down to much.

This same thing occurs with creature animations when you attack parts to the heads of creatures. The skin surfaces are calculated by the GPU but the placement of parts is calculated by the CPU. This is why you get strange clipping problems when you attack details to the lower jaw.

Given the choice of having the skin outside the collsion surface or inside the collision surface, you get a better visual effect if the collision surface is inside the skin. It gives the impression of touching the object as opposed to hovering on top of. Compare the experience of standing on a building vs. standing on a vehicle -- I prefer the effect of standing on buildings.

However, there are bugs in the collision logic that do not stop characters before they pass through the collision surface. And once passed though an outer collision surface, the character collides with some other collision surface. This gets the character stuck inside the surface. This happens with faster moving characters (speed 4 or 5; flight; falling from high distances; being knocked by damage. Changing the collision surfaces so that they are outside the skin won't fix this problem because it isn't a visual issue. The problem is that the collision logic fails.

DVDMaster wrote:However, there are bugs in the collision logic that do not stop characters before they pass through the collision surface. And once passed though an outer collision surface, the character collides with some other collision surface. This gets the character stuck inside the surface. This happens with faster moving characters (speed 4 or 5; flight; falling from high distances; being knocked by damage. Changing the collision surfaces so that they are outside the skin won't fix this problem because it isn't a visual issue. The problem is that the collision logic fails.

Wow, thanks for your in-depth reply. That explains a LOT on all accounts.

DVDMaster wrote:The second issue is collisions -- where does the character bump into the object. Collisions use the geometry of the actual pieces instead of a single bounding box for the entire building. And as you noted, it is separate from the visual skin of the building. Part of the reason that the skin is different from the collision surfaces is that the skin is generated by the GPU in the graphics card and the collsion surfaces are generated by the CPU. The collision calculations are done using a simple model -- here is a cube with these dimensions. What is sent to the GPU is more complicated -- here is a cube with these dimensions, with a certain thickness, with rounded corners with radius X, using this texture. The GPU takes that information and calculates all the surfaces needed to display it on the screen. The results of the GPU calculations cannot be sent back to the CPU to be used in collision detection and doing all those calculations with the CPU would slow things down to much.

This same thing occurs with creature animations when you attack parts to the heads of creatures. The skin surfaces are calculated by the GPU but the placement of parts is calculated by the CPU. This is why you get strange clipping problems when you attack details to the lower jaw.

Given the choice of having the skin outside the collsion surface or inside the collision surface, you get a better visual effect if the collision surface is inside the skin. It gives the impression of touching the object as opposed to hovering on top of. Compare the experience of standing on a building vs. standing on a vehicle -- I prefer the effect of standing on buildings.

Okay, I have another question for you DVDMaster. With this whole "collision" thing and certain parts being done by the CPU and other parts being done by the GPU, where does the planet collision system fall into all of this and why can't the buildings be done the same?

For instance, if you captain is standing on the surface of a planet, he appears to be standing directly on the planet surface. He isn't standing above surface but he also isn't standing just below the surface. However, you make a platform (out of a building) and your captain appears to be standing partially below the surface of that object rather than directly on the surface like that of the planet. So, it just seems that it shouldn't be too hard for the programmers to make it so collision surfaces appear the same as the graphics surfaces.

Yes, ignoring the whole collision "failure" problem at the moment. Just want my captain's feet to line up directly on the surface of an object like they do on the surface of the planet itself already.

iiiHuman wrote:
Okay, I have another question for you DVDMaster. With this whole "collision" thing and certain parts being done by the CPU and other parts being done by the GPU, where does the planet collision system fall into all of this and why can't the buildings be done the same?

For instance, if you captain is standing on the surface of a planet, he appears to be standing directly on the planet surface. He isn't standing above surface but he also isn't standing just below the surface. However, you make a platform (out of a building) and your captain appears to be standing partially below the surface of that object rather than directly on the surface like that of the planet. So, it just seems that it shouldn't be too hard for the programmers to make it so collision surfaces appear the same as the graphics surfaces.

Except that the are many more graphic surfaces than collision surfaces. For example, if you look that the cubical building piece (upper left on the bodies tap), there are just 6 collision surfaces (each face of the cube), but there are a lot more graphical surfaces -- approximately 50 (when you count each surface of the edge details). So from a computation stand point there would be about 9 times as many collision surface calculations. And this is just in a single building piece. And these types of calculations have been optiimatized in GPU's and not all that optimized in CPUs. So from a calculations per second perspective, using every single surface for collsions is just not feasable if you want the game to run on the largest number of computers possible. So it seems necessary to use collsion sufaces approximations instead of using the actual geometry of the buildings.

In addition, they may not actually calculate whether you hand or foot (or each body part) hits the surfaces or not. They just use a single center of mass point and compare the center of mass to the collisions surfaces to figure out where whether to prevent the character from moving in a direction or not. Then could send all the information to the GPU and let it figure out what parts are visible or not. GPU are optimized for these calculations.

I do think that a better decision could have been made about where to put the actual collision surfaces in each building piece. Right now, I think the collision surfaces correspond to the wire frame skeleton used to generate the skin model. This information that was already readily available from developing spore and concluded that that existing information was good enough for most adventures (or at least the adventures the developer team came up with). When building pieces are used for walls, the moving into the building effect isn't all that annoying -- who cares of a hand or elbow clips into the wall as you walk by. It would be less annoying than having the collision surfaces outside the building (like they are when standing on vehicles).

But creating a new collision geometry system is probably a very complex task.

A simple fix would be to provide some new building part bodies that don't have any round edges or complex edge details -- super simple cubes -- so that we could use these parts for building structures that we are to stand upon.

Just because you have fixed the visibility problem, you can still have problems with NPC walking on buildings.

It is my experience that any NPC activity on buildings as floors is buggy. Here is a very simple example:
NPC using basic AI, "mindless", patrol with way points.


If you change the building to a disguised gate (using the same building piece), you get better results:


However, you still have problems using a disguised gate as a bridge.


It appears that it uses the ground under the bridge for path calculations.

DVDMaster wrote:Except that the are many more graphic surfaces than collision surfaces.

They just use a single center of mass point and compare the center of mass to the collisions surfaces to figure out where whether to prevent the character from moving in a direction or not. Then could send all the information to the GPU and let it figure out what parts are visible or not. GPU are optimized for these calculations.

I do think that a better decision could have been made about where to put the actual collision surfaces in each building piece. Right now, I think the collision surfaces correspond to the wire frame skeleton used to generate the skin model.

But creating a new collision geometry system is probably a very complex task.

A simple fix would be to provide some new building part bodies that don't have any round edges or complex edge details -- super simple cubes -- so that we could use these parts for building structures that we are to stand upon.

Okay, wait a second. Let's see if we're on the same page here and she how complicated this really would have to be or not.

Let's start with a picture:



Now, for discussion's sake, let's say:

The Rounded Red Box is the sideview graphics cutout of a building piece that is not your standard cube (due to the rounded edges).

The Inner Dashed Blue Box is a simplified version of a possible frame for the actual object (the red box is the graphics for it).

The Outer Dashed Black Box is a better approximation of where collision SHOULD/COULD take place instead.

The Green Circle in the upper-right hand corner is an example of an additional graphic piece that could either be separate from or part of the original object.

With this in mind, it seems that the actual collision area could be computed by just adding to distance the surface of the inner frame is from its center. You could roughly compute this based on the outer flat surface of where the graphic will be drawn. Now, this shouldn't have to be computed each time (regardless of the size of the object) because, as you expand or contract the size of the object (changing the size of its inner frame), the outer edge of the graphic will also change in size accordingly and stay the same distance away from the edge of the inner frame. Creating a static value that can be stored.

For the most part, this should suffice. For the rounded corners (depending on how the inner frame is truly created), there might be a little bit of floating distance, but I believe this wouldn't be much of a problem for people when designing building parts that can be walked on etc.

In the case of the additional green circle (like the pylons on the corners of some building parts), they probably have their own inner frame (or center) that the distance is specified for. So, the same can be applied to that portion.

Best part is, even if the distance the graphic is drawn from its inner frame is different for each type of building piece, you wouldn't have to compute this each time. You would just have to store a static value to add to the distance of the inner frame to compensate for that graphic based on which object (type of building piece) was used. This would result in the outer dashed black box.

In fact, it almost seems that the "visibility" box around an object is partially based on this idea too (not sure). However, with the visibility box, it's computed on the outermost edge of the farthest part of the object. Which, of course, would be very bad to use as then you'd have a collision surface WAY OFF.

But, it seems it gets even better. By using a stored static value of a distance from the edge of the inner frame, the visibility box could be equal to that of the new collision box using the method I'm describing. Of course, there'd still need to be the computations of what can be seen at a certain angle etc. But, that wouldn't affect the predetermined collision surface distance. Also, by using the stored static value, the GPU can use that prestored value to help with its computations of where to draw the actual surfaces of the object and cut down on some of the computing for it.

As for textures, that doesn't matter since those are flat and drawn on the surface and do not affect the actual shape of the object.

In fact, since computations have to be made as to how and where to draw textures on an object (how far from the framework, etc), another possibility could be to use at least part of those computations to maybe determine the collision surfaces. Once they are computed, temporarily store those values for collision detection.

Now, it would help a lot to know exactly how they are computing object frames and graphic surfaces etc. Then, we could better determine an appropriate and simple solution. The point is, I think there is a simple solution without causing much more computations having to take place.

However, you might have a better grasp on what they are doing and can explain where I'm wrong here. Which, I actually look forward to since it still seems like there's tons of acceptible possibilities to fix the problems and get around it being lots more complicated.

DVDMaster wrote:Just because you have fixed the visibility problem, you can still have problems with NPC walking on buildings.

It is my experience that any NPC activity on buildings as floors is buggy.

It appears that it uses the ground under the bridge for path calculations.

Yeah, those videos clearly show that there are definitely bugs in path calculations. I think the biggest problem there is that the paths do appear to be computed using the surface of the planet rather than the surface of the top object being crossed. I say the top object since you can have a floor above another floor etc etc. But, the top object being the one being crossed not including any more above it (like a ceiling etc). Just to be clear.

iiiHuman wrote:

With this in mind, it seems that the actual collision area could be computed by just adding to distance the surface of the inner frame is from its center. You could roughly compute this based on the outer flat surface of where the graphic will be drawn. Now, this shouldn't have to be computed each time (regardless of the size of the object) because, as you expand or contract the size of the object (changing the size of its inner frame), the outer edge of the graphic will also change in size accordingly and stay the same distance away from the edge of the inner frame. Creating a static value that can be stored.

For the most part, this should suffice. For the rounded corners (depending on how the inner frame is truly created), there might be a little bit of floating distance, but I believe this wouldn't be much of a problem for people when designing building parts that can be walked on etc.

Yes. This is all doable. Is just that you they'd have to build the data structures for all this additional information and then check every possible place where any of the geometry is accessed and decide at each instance wether to use the current inner box or your proposed outbox.

iiiHuman wrote:
In the case of the additional green circle (like the pylons on the corners of some building parts), they probably have their own inner frame (or center) that the distance is specified for. So, the same can be applied to that portion.

I'm not sure whether they have their own inner box for collision or not. I haven't done enough testing. It may be that those corner pieces only have skin geometry that only exists on the GPU and not the CPU.

iiiHuman wrote:In fact, it almost seems that the "visibility" box around an object is partially based on this idea too (not sure). However, with the visibility box, it's computed on the outermost edge of the farthest part of the object. Which, of course, would be very bad to use as then you'd have a collision surface WAY OFF.

From what I can tell, there is just a single visibility box for the entire building. So when you have complex building shapes, the visibility bounding box is very different from the skin box.

iiiHuman wrote:
But, it seems it gets even better. By using a stored static value of a distance from the edge of the inner frame, the visibility box could be equal to that of the new collision box using the method I'm describing. Of course, there'd still need to be the computations of what can be seen at a certain angle etc. But, that wouldn't affect the predetermined collision surface distance. Also, by using the stored static value, the GPU can use that prestored value to help with its computations of where to draw the actual surfaces of the object and cut down on some of the computing for it.

That is what they are already doing. They are telling the GPU to draw a cube with rounded corners with a given radius with walls of a given thickness. It is just that they are using the coordinates of that box for the collision surface. What they need what you suggest -- calculate a new collision surface that takes into account the thickness of the walls and the radius of the rounded corners.

One of the basic challenges is that while the GPU is good at these calculations, it isn't really good at passing the results back to the CPU. So to implement your solution, these additional calculations would have to be done on the CPU.

In addition, it doubles the amount of information needed to be kept in memory -- they tell need the existing inner box for drawing the skin and your suggested outer box is a addition.

Tairon96 wrote:It is not easy to get a NPC using a bridge, but it is possible. You have to
* use a disguised gate as bridge
* connect both shores with a thin languet under the bridge (no ship can pass this bridge now!)
* use invisible gates to prevent the NPC use the natural bridge.
* tell the NPC with several waypoints the correct way

Spore - NPC walking over a bridge


(The fat crab like creature is my test captain. The small guy with the big red key opening the red gate is the npc crossing the bridge.)



And this is the way how it looks like in the editor:

Tairon96 wrote:It is not easy to get a NPC using a bridge, but it is possible. You have to
* use a disguised gate as bridge
* connect both shores with a thin languet under the bridge (no ship can pass this bridge now!)
* use invisible gates to prevent the NPC use the natural bridge.
* tell the NPC with several waypoints the correct way

Spore - NPC walking over a bridge


(The fat crab like creature is my test captain. The small guy with the big red key opening the red gate is the npc crossing the bridge.)



And this is the way how it looks like in the editor:

Has anyone tried this (or something similar) with vehicles? Would be cool to see a tank actually cross a bridge.

iiiHuman wrote:

Tairon96 wrote:It is not easy to get a NPC using a bridge, but it is possible. You have to
* use a disguised gate as bridge
* connect both shores with a thin languet under the bridge (no ship can pass this bridge now!)
* use invisible gates to prevent the NPC use the natural bridge.
* tell the NPC with several waypoints the correct way

Spore - NPC walking over a bridge


(The fat crab like creature is my test captain. The small guy with the big red key opening the red gate is the npc crossing the bridge.)



And this is the way how it looks like in the editor:

Has anyone tried this (or something similar) with vehicles? Would be cool to see a tank actually cross a bridge.

I will be trying to do this soon.
I have an adventure - in the making - that has a continent to which a "life-form" - made island is attached.
I have a vehicle crossing from the island to the continent and back.
This currently uses a land-bridge, though I want to use a building-bridge, as I stated earlier.
I shall post here with the results-if I remember.

VERY IMPORTANT MESSAGE
I found an easier way to get rid of the awareness problem, and a very simple one too! If you disguise a gate as the building (as in the 8/2 update) enemies and allies are completely aware of everything around them, disabling that annoying view box. Hope this helps!

JuJar wrote:
I will be trying to do this soon.
I have an adventure - in the making - that has a continent to which a "life-form" - made island is attached.
I have a vehicle crossing from the island to the continent and back.
This currently uses a land-bridge, though I want to use a building-bridge, as I stated earlier.
I shall post here with the results-if I remember.

Just a quick note to clarifyTairon96's method. He is putting a disguised gate on top of a land-bridge.