EntityOrder problems? Typical....
Blitz3D Forums/Blitz3D Beginners Area/EntityOrder problems? Typical....
| ||
| Yes, here I am again with yet another problem. Here's a screenshot without making "rifle\entityhandle" ordered:  And here's one where it IS ordered (at -4)  What's wrong? |
| ||
| The near clipping plane is clipping the rifle. Set your near clipping plane to something less. Looking at your other post, you have it set to .1, try .05. |
| ||
| no, that's an old screenshot above. disregard the near clipping - it's fixed. what I want you to look at is the fact that the rifle in the second picutre is dissected. eh? |
| ||
| looks like some of the normals have been flipped. |
| ||
| Looks like the entity order command has only affect some of the rifle. Is it made up of many parts? Different meshes? |
| ||
| nope - one single mesh - "w_xm1014.3ds" |
| ||
| I think that part of the gun is actualy behind the camera, but, is being forced to be rendered anyway. I think that's whats causing the order problem. Try this. Hide the gun. Render the world. Set the cam mode to NOT clear the Z-Buffer (cameraclsmode) then, hide the world, and render just the gun. That way, it will always be on top. You can either hide the world, move the camera out of the world, or set the camerarange really small, so your only rendering the gun, in the second render. |
| ||
Eh? That didn't work at all.While Not KeyDown(1) UpdateCamera() RenderWorld CameraClsMode camera, 1, 0 HideEntity level1 UpdateGun() UpdateBullets() UpdateWorld ShowEntity level1 UpdateParticles() UpdateEnemies() UpdateMiscActions() ;draw crosshairs RenderWorld DrawImage hairs, 400, 300 UpdateGUI() Flip Wend |
| ||
| Setting an entity's order to non-0 also disables z-buffering for the entity, so should be only used for simple, convex entities like skyboxes, sprites etc. |
| ||
| Errr, I am probably thick, but why do you need to set the entity order on the rifle at all? If it is positioned correctly in your world, then it should render correctly? |
| ||
| If it is positioned correctly, it goes through walls. I want to render the gun first. |
| ||
| "what I want you to look at is the fact that the rifle in the second picutre is dissected." You should have mentioned this right off the bat. It both amuses and annoys me when people do stuff like posting some random code and asking "what's wrong?" or they don't say anything because they think the subject line is enough information. At any rate, WolRon is right about the z-buffering. That is, when you use EntityOrder you turn off z-buffering for the object, so polygons within the object are no longer sorted correctly. This doesn't matter for seamless convex models (since polygons on the far side of the model are all facing away and thus culled,) but for models with overlapping parts this will screw up rendering. Without z-buffering the renderer won't know which polygons are on top of which. The solution is to redo your model so that it is convex and parts aren't overlapping. |
| ||
| The old second camera trick works for me. Create a second camera and position it far away from your arena using similar code to that below. Parent the gun to the camera in the same relative position as it would be to the player character's main camera. When the player character rotates, also rotate the second camera to get correct lighting on the gun. Global HUD_camera Function CreateHUD() ; -- Setup HUD camera HUD_camera = CreateCamera() PositionEntity HUD_camera, 0.0, -500.0, 0.0 CameraRange HUD_camera, 0.2, 3.0 CameraZoom HUD_camera, 1.6 CameraClsMode HUD_camera, False, True EntityOrder HUD_camera, -1 End Function |
| ||
| I'm thinking, would you be seeing the gun at any other angle? Why not just make it into a sprite or textured quad? Then you wouldn't have to worry about z buffer problems with entity order. |
| ||
| Wepaon changing might be a problem, if you move the weapon out of view, and move a new one in :o) The second camera trick certainly does the trick tho. |
| ||
| Why not just set the collison sphere so that the weapon can't go through the wall???? Easiest solution yet. |
| ||
| Trouble with making the collision sphere that large is that the player won't be able to fit into spaces he ought to. The gun is a narrow protrusion out front, so encompassing it into the collision radius would mean the collision sphere would extend way out from the player in all directions. |
| ||
| Not if you use a seperate sphere for the weapon... |
| ||
| Then the weapon would move away from the player if it hit a wall. |
| ||
| I guess you used LoadAnimMesh for the Gun? Well, probably you simply want or need to use an animated Mesh for the gun, as I do too. I had this Problem too, when I worked on my first FPS Demo. My solution was to downscale the weapon that much that it never would sink into a wall or something. Of course, this also requires to position it closer to the camera center. Probably, when the weapon looks too long-stretched this way, you need to scale the depth of it even smaller than the rest (a camera-zoom issue) |
| ||
| My understanding of using the EntityOrder command is that it disregards which triangles come first (from greater distance to lesser distance) and instead draws the triangles in the order they are read from the file. Therefore, perspective remains, but triangles that are supposed to be behind something are in front of it sometimes, for example. At least, I think this is how it causes the problems. My only suggestion is to do this: Completely get rid of the EntityOrder, as it only messes up the meshes. To solve the problem involving guns stuck in walls, try attaching an invisible sphere as a parent entity to the camera. Position it in front of the camera and scale so it creates a semi-'shield' in front of the camera. Then, perform sphere collision testing (as accurately as possible with both x and y radii) with your invisible sphere, and therefore the camera's regular radius remains except for the 'shield' in the front. So, basically, it'll be shielding your player from moving into a wall too far forward, yet allowing the usual radius collision testing for +y,-y,+x,-x, and -z. Sorry if it's counfusing. I'd make some code for you, but I haven't the faintest idea how big the gun is, your usual player radius, and other stuff like that. |
| ||
| It's called "EntityRadius." But the guns always go through the walls, no matter ho much I try. Axeman - you rock. |
   |