Rick

Even still. Each model can be loaded individually first so you see the progress bar moving, then load the terrain last. At that point the user is at least seeing a visual update of each loaded model. Then load the terrain last. Even if it takes slightly longer it's not a big deal at that point. The user knows the load is almost finished. The only startup delay would be parsing the original sbx file and that should only be a few seconds. I so wish the sbx file was in xml format btw. Would be so much easier to parse.

I'm able to live with that. I don't think the Terrain takes all that long. Plus it can be viewed as a model like any other. I don't think the goal here is to make it multi-threaded so there is no freeze, instead we make it so between model loading (freezing) we can update the screen with a progress bar. So yeah, there will still be freezes when loading a model but because we are able to just load 1 model at a time we can update the screen in between.

Perfect, thanks. I can work on parsing it out into 2 separate files at work over lunch. You know looking at this, I think I might even just break out each section into it's own file and call LoadScene() on that file. It would just be 1 file that keeps getting overwritten, but it's nice and easy because then I don't have to write the loading code for the models. LoadScene() will handle that but each sbx file I sent it will just have 1 model/terrain at a time.

The contents of the data inside it, posted in the forum here. (A small example that doesn't have a ton of models in it)

Some do, and this has a chance to. Can someone post here a sample sbx file that has a terrain with veggie system and a few models? I don't have access to a file where I am.

Do what Niosop said. And after you are finished share it with the rest of us It's kind of a pain, but take the sbx file and in code break it into 2 separate sbx files. One with the terrain and terrain vegetation and the other with all the other models. The call LoadScene() on the new sbx file that has the terrain and vegetation in it and then manually parse out the other sbx file that has the models in it. I think that is the best we can do now, even though it sucks, once someone writes it we should all be able to use it. Then you would be a hero. Just allow a callback method that gets called after each model is loaded passing in the % done. I'll eventually have to do this anyway so I might tackle it this weekend. I hate parsing files with C/C++ though.

So I wrote this little test program, but I still can't see what the relationship between the mesh scale vs the texture scale to get it to work right. It's almost as if I need the texture size and keep it scaled to that size no matter what the size of the model, so it'll tile itself at the same size all the time // ==================================================================== // This file was generated by Leadwerks C++/LEO/BlitzMax Project Wizard // Written by Rimfrost Software // http://www.rimfrost.com // ==================================================================== #include "engine.h" #define PI 3.14 void ScaleTexture(TEntity mesh, TVec2 uvscale, TVec2 center = Vec2(0,0)) { for (int iSurf = 1; iSurf <= CountSurfaces(mesh); iSurf++) { TSurface surface = GetSurface(mesh, iSurf); for (int iVert = 0; iVert < CountVertices(surface); iVert++) { for (int texcset = 0; texcset < 2; texcset++) { TVec2 uv = (GetVertexTexCoords(surface, iVert, texcset) - center) * uvscale + center; SetVertexTexCoords(surface, iVert, uv, texcset); } } } UpdateMesh(mesh); } int main( int argn, char* argv[] ) { Initialize() ; RegisterAbstractPath("C:/Leadwerks Engine SDK"); SetAppTitle( "Test05" ) ; Graphics( 800, 600 ) ; AFilter() ; TFilter() ; TWorld world; TBuffer gbuffer; TCamera camera; TMesh ground; TLight light; TMaterial material; world = CreateWorld() ; if (!world) { MessageBoxA(0,"Error","Failed to create world.",0); return Terminate(); } gbuffer=CreateBuffer(GraphicsWidth(),GraphicsHeight(),BUFFER_COLOR|BUFFER_DEPTH|BUFFER_NORMAL); camera=CreateCamera(); PositionEntity(camera,Vec3(0, 15, 0)); RotateEntity(camera, Vec3(90, 0, 0)); float FOV = 60; CameraZoom(camera, 1.0f / tan((FOV * (PI/180))/2.0f)); material=LoadMaterial("abstract::grid.mat"); ground=CreateCube(); ScaleEntity(ground,Vec3(1,1,1)); PositionEntity(ground,Vec3(0,0,0)); PaintEntity(ground,material); light=CreateDirectionalLight(); RotateEntity(light,Vec3(45,45,45)); float xScale = .5; float zScale = .5; // Game loop while( !KeyHit() && !AppTerminate() ) { if(KeyHit(KEY_A)) { xScale += .5; ScaleEntity(ground, Vec3(xScale, 1, zScale)); } if(KeyHit(KEY_W)) { zScale += .5; ScaleEntity(ground, Vec3(xScale, 1, zScale)); } //ScaleTexture(ground, Vec2(xScale, zScale)); //ScaleTexture(ground, Vec2(xScale, zScale)); if(KeyHit(KEY_NUMADD)) ScaleTexture(ground, Vec2(.5, .5)); if(KeyHit(KEY_NUMSUBTRACT)) ScaleTexture(ground, Vec2(1.5, 1.5)); // Update timing and world UpdateAppTime(); UpdateWorld(AppSpeed()) ; // Render SetBuffer(gbuffer); RenderWorld(); SetBuffer(BackBuffer()); RenderLights(gbuffer); // Send to screen Flip(0) ; } // Done return Terminate() ; }

I think it draws on the current buffer. Because you can create and set a buffer and use DrawText() on it. The name tag function Lum created in Gamelib does this.

That's true, unless they draw to the current buffer. Not sure.

I think it's possible. I think camera in one of the worlds needs to not erase itself so it'll show through. As long as you draw 2D stuff after the render of that world it'll be on top of that world. But drawing worlds on top of worlds overwrites unless certain things are setup.

I think all your 2D drawing commands need to be right before Flip() AND after the rendering of the world. What you have it seems to draw the rect but then later you render the screen, which I'm guessing is drawing the 3D world over your rect.

I agree the shader would be the most correct but it's something I'm not familiar with and don't want to spend the time to learn at this moment. I just want to get a finished product and then later I can go back and work on speeding certain areas up. So how would one go about modifying the texture coordinates to get this result? The code I have above seems to modify the texture coordinates but it doesn't seem to give the results that 3DWS is giving.

Here is a video that shows the effect I'm looking for So notice that as I'm scaling the mesh the texture just repeats itself indefinitely. That's what I'm after. When a part of the crack in the earth is established it doesn't change, only it's tail grows but the existing parts stay put. So this is from 3DWS. If I could duplicate that, everything would be perfect.

So doing this real-time in code is pretty much not an option because of the speed I assume? Also, this seems to be kind of hardcoded in the mat file if I need to change the alpha to determine the value. How do programs like 3DWS handle this sort of thing? If I apply a texture onto a block in 3DWS it tiles itself. If I extend that block no matter how long the new area of the block is just tiled with the same texture. That's the sort of effect I'm looking for. As my plane is growing I want the texture to just repeat over and over again no matter how scaled it gets.

I use this, something Master posted, but if I put this after the scale and call it each frame I basically get 0 FPS. It also freezes my game for a few seconds if I call this only once. The plane that I create has 64 x & z segments so not sure if that's the reason. Although it requires a high number of segments to be able to hug the terrain correctly. void EarthQuake::_ScaleMesh(TEntity mesh, TVec2 uvscale, TVec2 center = Vec2(0,0)) { for (int iSurf = 1; iSurf <= CountSurfaces(mesh); iSurf++) { TSurface surface = GetSurface(mesh, iSurf); for (int iVert = 0; iVert < CountVertices(surface); iVert++) { for (int texcset = 0; texcset < 2; texcset++) { TVec2 uv = (GetVertexTexCoords(surface, iVert, texcset) - center) * uvscale + center; SetVertexTexCoords(surface, iVert, uv, texcset); } } } UpdateMesh(mesh); } How can I get the texture to not scale with the mesh and instead just tile?

OK, so I'm really close. I have a growing plane that has a crack texture that reaches the mouse destination over time. I just need to figure out how to make the texture not scale with the plane and it will be perfect (minus my crappy programmer art). The crappy part about this is that the real-time updating of the plane to hug the terrain drops my FPS from 88 to 33 . Whisper where are you with the shader solution for this?

Here is how you would change the FOV float FOV = 60; CameraZoom(camera, 1.0f / tan((FOV * (PI/180))/2.0f));

Yeah, I'm trying to scale a mesh from 1 point to another. I kind of have it working although I don't know 100% why it works. I put a pivot at the point of a character and another at the point of where the mouse is clicked on the terrain. Between these 2 points I get the distance between the x & z only. I then use that distance / 10 in the z value of ScaleEntity() and it seems to scale the plane correctly. I also point the character pivot to the mouse clicked pivot and then rotate the plane along the y. This all works, although I don't know why 10 is the magic number to divide by the distance. I also need to increase the segments of the plane a lot since the scale distance can be pretty far it needs a ton of segments in order to hug the terrain. TPick p; CameraPick(&p, GetLayerCamera(GetFrameworkLayer(0)), Vec3(MouseX(), MouseY(), 5000)); TPivot mousePivot = CreatePivot(); TPivot ownerPivot = CreatePivot(); // TODO: This doesn't work, but we only want to set things if it's on the terrain only if(p.surface != 0) { PositionEntity(mousePivot, Vec3(p.X, p.Y, p.Z)); PositionEntity(ownerPivot, GetOwner()->GetPosition()); TVec3 p1 = EntityPosition(mousePivot); TVec3 p2 = EntityPosition(ownerPivot); // Get 2D distance float x = p2.X - p1.X; float y = p2.Z - p1.Z; x = x * x; y = y * y; float distance = sqrt(x + y); PointEntity(ownerPivot, mousePivot); RotateEntity(_plane->GetPlane(), Vec3(0, EntityRotation(ownerPivot).Y, 0)); //float distance = EntityDistance(ownerPivot, mousePivot); ScaleEntity(_plane->GetPlane(), Vec3(1.0, 1.0, distance/10)); ShowEntity(_plane->GetPlane()); }

Is there a way to convert the value returned from EntityDistance() to a value to pass as a scale to ScaleEntity()?

There is no doubt in my mind that most anything can be done with shaders. Unfortunately I don't know shader programming and if I ever want to actually complete a game I'm not going to have time to get into shader programming. Maybe I'll mess around with it a little here and there, but for now I'm not going to delay the project to learn shader programming. I wish I had more time to dig into it though because I know it's powerful. Maybe someone should create an easier wrapper around shader programming. Kind of like a library on top of the different shader languages.

I was thinking about that also, but I don't think that would give the correct visual. Plus wouldn't I need to deal with transparency over the part of the terrain that's the crack hasn't reached yet because I wouldn't want that part to have anything on it (or let the ground show through). The visual thing I'm thinking is if I move the texture "forward" towards the target it wouldn't look like it would if it was real because if the ground would start to split right by your feet that first cracking part would be done and not change again, but if I was moving the texture "forward" the part by my feet would always seem to be changing as the texture is moving. The crack will have bends and turns in it. That's why I was thinking of just growing the plane and having the texture stay the same. The texture by my feet and beyond wouldn't be changing at all and that would be the effect for something like this.

So I have this idea for an ability in my game. The character will select a target and slam his first on the ground. It will then create a crack in the earth that starts at the character and go to the target. Here is how I'm thinking of doing it and I'm just curious of how other people would handle this. The crack in the earth would just be a texture. It would be a pretty small crack so I figure an artist would be able to make it look like it has some kind of depth. I would make a plane that would scale to the attacker to the target. I would then use the terrain hugging on the plane to make it fit the terrain. I'm wondering though how to make the crack look like it's traveling from the star to the finish. I could scale the plane over a few frames until it reaches it's goal and the texture on it would need to stay the same size (not scale with the terarin) and be repeatable with seamless transition from start to end. Does that seem like the way to go about this or am I missing something?

Interesting. I mean how hard would this be to get it working? LoadMaterial() obviously already does what is needed.

I implemented rising numbers of the amount of damage or healing that is happening to a unit. I spent a decent amount of time to have it like a billboard so it had depth but I think I'm better off just using DrawText() instead. It looks better. I made the the Shield Slam cause 5 damage and it worked very well. Just 1 minor bug with the way the health bar is drawn on the right hand side. Instead of the just the width to worry about like the left hand side I need to change the x value and the width. Everything seems setup to just mass add abilities so that's what I'll be doing over the next few weeks. Time to just start brainstorming on all sorts of different abilities. I'm open for suggestions also.

1. I try to create the material from code (to try and remove an external mat file dependency) but when I do it, it doesn't seem to have transparent BG. (I apply this to a plane created in the transparent world of the framework. My code mat = CreateMaterial(); SetMaterialKey(mat, "depthtest", "1"); SetMaterialKey(mat, "overlay", "1"); SetMaterialKey(mat, "blend", "alpha"); SetMaterialKey(mat, "zsort", "0"); SetMaterialKey(mat, "castshadows", "0"); SetMaterialKey(mat, "collisiontype", "0"); SetMaterialShader(mat, LoadShader("abstract::mesh_diffuse_billboard.vert","abstract::mesh_diffuse.frag")); Mat File, that when loaded, works perfectly texture0="abstract::nametag.dds" depthtest=1 overlay=1 blend=alpha zsort=0 castshadows=0 collisiontype=0 shader="abstract::mesh_diffuse_billboard.vert","abstract::mesh_diffuse.frag" Note that the texture is just a dummy placeholder as we replace that with a buffer later. So in the mat file above it's really pointless.