Jump to content
Ultra Engine Community

Scott Richmond

Members
 View Profile  See their activity

  • Posts

    422

  • Joined

  • Last visited

 Content Type 

Posts posted by Scott Richmond

    Model->SetViewRange() causes crash!

    in Programming

    Posted

    Ok so I've just tried it. Unfortunately its not giving me the speed-up I thought it would. I would have thought that objects outside the set distance would do a hide(), but they don't. I don't get nearly the speed I would if I did a hide(). Why is that? Is it because the models still take up time when the engine has to check each one and do a distance calc?

    How can I avoid that? Would be good if I could extend the distance culling function to get it to hide models as well.

    Model->SetViewRange() causes crash!

    in Programming

    Posted

    I'm developing something that requires creation and destruction of entities at runtime, so I've just been doing some tests and getting my framework going and I've noticed that when I call Model->SetViewRange() on a pointer to a Model entity it crashes! I thought for awhile that maybe its simply bad coding on my part like some sort of pointer out-of-scope issue, but the following fairly simple code does not work.

    Can someone browse over it and confirm I'm not doing anything silly before I officially put in a bug request?

     

    int main (int argc, char *argv[])
{
// Set graphics mode
Engine engine("3DF",1024,768);
engine.AddAbstractPath( "./Data" );

Framework fw(CREATENOW);
fw.main.world.SetAmbientLight(Vec3(0.13,0.14,0.17));
//fw.main.world.SetCullRange(...);

Cube box1(CREATENOW);
box1.Move(0,0.3,4);
box1.SetColor(Vec4(0,0,1,1)); //Blue 
box1.SetViewRange(VIEWRANGE_NEAR, RECURSIVE);

Sphere ball1(CREATENOW, 16);
ball1.SetColor(Vec4(1,0,0,1)); //Red
ball1.Move(-1,0,4);
ball1.SetViewRange(VIEWRANGE_NEAR, RECURSIVE);

Sphere ball2( ball1.Copy() );
ball2.Move(2,0,0);
ball2.SetColor(Vec4(0,1,0,1)); //Green
ball2.SetViewRange(VIEWRANGE_NEAR, RECURSIVE);

Cube ground(CREATENOW);
ground.SetPosition(0,0,0);
ground.Move(0,-1,5);
ScaleMesh(ground,Vec3(100,1,100));

Model *leModel = new Model();
leModel->Load("abstract::crates_small.gmf");
leModel->Move(3,0,0);
leModel->SetViewRange(10, RECURSIVE); /* <----- CRASH: Comment this line out and it will run fine */

DirectionalLight lig2(CREATENOW);
lig2.SetShadowmapSize(1024);
lig2.Turn(5,0,0);

OcclusionCulling(false);
SetWireframe(false);
SetStats(2); // Detailed stats

PlayerController playerController;

Game game;

while( !Keyboard::I****() && !engine.IsTerminated() ) {

	fw.Update();

	char msg[256];
	sprintf( msg, "Camera Pos: %fx%fy%fz",  playerController.getPosition().X,
											playerController.getPosition().Y,
											playerController.getPosition().Z);

	if( !engine.IsSuspended() ) {
		playerController.update();
		fw.Render();
		DrawText(0,250,msg);

		engine.Flip( 0 );
	}

	game.updateMessageQueue();
}
return engine.Free();
}

    Texture Splatting

    in Programming

    Posted

    The map matrix is made up of tiles/blocks. So at its heart I suppose its minecraft, if you want a visual reference. However I'm running it through an algorithm that outputs the surface and smooths it. So the output is a polygonal volume. I then need to paint it. I just got a reply from Josh regarding this and he said the following:

    This feature is not supported. However, it's simply a matter of writing a shader that combines two textures based on vertex color. I've seen an example someone posted of this in action, but I don't remember where. You might look in the old forum if you can't find it here:

    http://www.leadwerks.com/forum/

     

    Blending between an arbitrary number of textures is a much more difficult proposition; well not just difficult, but impossible, due to the limited number of texture units you have to use.

     

    As Josh mentions, surely this work has been done before? If not for LE specifically but in shaders in use elsewhere?

    Texture Splatting

    in Programming

    Posted

    Thanks for your input Paramecij. Are you suggesting I manually create transitions between all the different types of tiles? I do not like the sound of that at all.

    Surely there is a more modern approach - The article I linked in the original post sounds really nice.

    Texture Splatting

    in Programming

    Posted

    Just a polygonal mesh. I iterate over my terrain matrix, get the 'outside shell' and place all the vertex's I need and draw polys over them.

    It works really well, but I have as yet worked out how to texture such a mesh in LE.

    Texture Splatting

    in Programming

    Posted

    I'm currently working on a small isometric RPG concept and I'm having a bit of trouble working out how I'll do the terrain. What I'm working with is basically a 3D matrix database of cubes that make up the map. To draw the terrain I'm currently going to render out a big mesh from the data, which I've got sorted. But I'm unsure how I'm going to blend together the various terrain types.

    I've done some limited research and found a few nice articles:

    http://www.m4x0r.com/blog/2010/05/blending-terrain-textures/

     

    How would I apply this to LE? Has anyone had any previous experience with this?

    Occlusion Culling Options

    in Programming

    Posted

    Agreed. And that approach can be taken further by stitching the cubes together and generating an outer shell as well. It is something I have thought about. But, I may yet still choose to go for a model approach if I'm not getting the quality I want with simple primitive cubes. And if thats the case, then I won't be able to apply such optimizations.

    The game concept is fairly open-ended at this point.

    Occlusion Culling Options

    in Programming

    Posted

    I'm prototyping a small 3D isometric game and I'd like to have the ability to drop in, for example, 30,000 cubes as a floor. Or really, any number of models and assorted items. But the point is - There would be lots over a large area. The question is, how can I cull unseen objects in an efficient manner from the render pipeline?

    Using an isometric camera I'd only ever be looking at maybe 10% of the total amount of entities out there.

    Would I:

    1. Render all entities on the map and then try to cull them by:

    1a. Using the LE2 OC - I've tried this and it appears very inefficient in general. I think the time its taking to traverse the entity list is larger than just rendering the primitive cubes I'm testing with. I also have heard that if I group entities together into larger chunks, it would help a lot. However I don't know how?

    1b. Try to organise the entities into some form of octree and .hide() .unhide() them based on region.

    2. Don't render everything in the first place. Only create and render the objects the player is looking at by keeping track of camera position. Delete entities as they fall out of range. But would this create lots of stutter as the player scrolls around?

     

    Addendum: I also heard that, for example with these cubes I'm testing with, if I copy instead of create for each cube that helps? Any documentation on this?

     

    Any other ideas? Tips on how to render faster?

    Newton vs Bullet demo

    in Programming

    Posted

    It's a case of accuracy versus performance. The Bullet boxes slide forward at the base and the entire stack collapses. The Newton stack collapses from the top, and a stable base is left over. Most physics libraries can't handle stable stacking of very many objects.

     

    If your game is "dodge 500 falling boxes" then I can see how the first would be better, but I tend to favor stable interactions of simple things like doors and jointed machines.

     

    We'll probably switch to PhysX or Bullet, but you will see errors in simple behavior, and you will have to deal with stability issues you take for granted right now.

     

    Not interested in Havok?

    Engine static lib

    in Programming

    Posted

    What is the actual advantage to doing this? I don't fully understand the difference but it sounds like a lot of work to simply avoid having a small amount of DLLs in the root directory of the game.

Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...