-
Posts
7,936 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Everything posted by Rick
-
The idea with the grass was that you could make rope with it and rope would be used in making other things as well. After harvesting a grass patch it would go away and other grass would grow somewhere else over time to keep a certain coverage of grass at all times so doing some tricks like other games where grass is purely for visuals won't necessarily work in this situation. This concept is the base concept for the game. Trees get cut down for wood and you have to plant new trees or else you can end up with no more trees. Same for bushes, corn and other plant food. The idea is to then turn this into a persistent multiplayer (network code is being thought of the entire time, this singpleplayer is just to get the basics down and see how it plays) game to watch how the world grows and evolves. I'm making a client updater so I can start basic but people can play sooner and keep expending functionality over time, but I want players to be able to start playing the game right away. Sort of taking on the Minecraft way of developing. See if you can get people to pay for a betaish game with free updates for the game forever.
-
If that was a joke then otherwise (it's the internet so I can't read emotion all that well ) I think Zaphos plans on adding attachable gear and many textures like some MMO's do. He'll sell the gear to be prebuilt to be easily attachable to his models. I'm really excited about that because you don't see that all that much in the indie modeling world and I think there is a huge market for it as most everyone wants to make some kind of RPG it seems (including me) and gear is generally a pretty big part of those games.
-
Cool. So a couple things I did was use EntityViewRange() on all my models and set them to the lowest parameter allowed since it's top/down kind of view they don't need to be seen very far away. This worked really well actually, but I feel it's still not the real reason behind the slowdown. With that and with grass (but without shadows on grass) I was still only getting about 50 fps. Without grass I get about 100 fps so for now I'm going to just remove grass as a resource in my game. It'll take a little restructuring of the game but not the end of the world. Thanks for all your tips and I'm sure I'll come back and visit this at a later date if the game gets far enough along but for now I'll focus more on the gameplay.
-
Very nice. I'm excited for this character and it's accessories!
-
Yeah that's what I did, but it's still ended up being about 40x40 (because once I found the tile the player was on, given what the camera can see I would go 20 tile in both direction from the player) grid which seemed to take a decent amount of time when doing every frame. So right now it seems all the grass amount is really what's hurting. To help I changed the view distance on all the loaded models since it's a top/down view I simply have a short distance where the engine will show/hide on it's own via the EntityViewRange() function. This actually helped a ton. I also turned off shadows for grass. That gave me about 50 fps which was better but still not the best. For now I've just removed grass which now gives me 100+ fps which is great. Grass was going to be a resource for my game so now just rethinking how I can get that resource.
-
Yeah that always gets ya because it doesn't seem Josh always announces these the best way. We need like a giant banner on every page for a week that says "NEW UPDATE!!!!"
-
I guess you'd have to post your code because if you said you set the correct entity types and collisions with the right collisions response (last param to Collisions()) then it should work.
-
Another work around might be to use the message as a flag to indicate to read some entity key that you set in C for that entity. Basically telling Lua that you updated an entity key value attached to this entity. Something like: SetEntityKey(ent, "speed", "25"); SendEntityMessage(ent, "updated.speed"); Then in the lua entity message function look for "updated.speed" message and when you see it read the "speed" entity key from the model.
-
I agree. I'll check that out when I get home. So shadows must increase the entities drawn number as well in those stats..
-
I think in Lua that extra parameter can only be a string (remember reading a thread about that). So once you are able to send strings you'd have to send your number as a string and in Lua convert it to a number.
-
I'm at work atm so can't answer that but I think those modelviewer shots might have that in the bottom left if I remember? If not then the total poly count on the screenshots will give an indication. That being said it doesn't seem like the poly count is the issue. If I have no lights in my scene the entities drawn is correct with how many models I have visible. As soon as I add a directional light (haven't tried other lights) the entities drawn goes crazy high. Would the poly count have any affect when lights are added to a scene like I'm seeing? Why would it add more entities drawn once lights are in the mix? Shadows maybe? Maybe I can try turning off shadows for the gras or something?
-
So you create a character controller for the player and that's what you are setting the entity type on? Did you also give it the character controller a mass?
-
You should be able to just cast whatever you are sending to (byte*). I'm not 100% sure of the conversion between C++ and Lua however. When everything is in C++ that type can be anything and casting it works. Try something like: C++: string test = "hello"; SendEntityMessage(ent, msg, 0, (byte*)test.c_str());
-
@Josh, if you look very closely you can see there are grass models like in the others scenes. Grass is making up most of the models so the count of 300 is accurate. Also, I'm using C++ now (got your msg just this morning). Was using Lua but switched the program to C++ because I was attempting the ForEachEntity function to see if I could work around this issue. I can create a zip file with this scene but remember that the actual LE scene from the Editor is just the terrain and the 1 character model. Everything else is loaded at run-time so not sure if you'll get the same debugging ability you are looking for with the scene. I'll package this up in a zip tonight. Not that I can see.
-
When you say grouping what specifically do you mean? Parenting them to a pivot every 16x16 tiles or something like that?
-
TEntity scene = LoadScene("abstract::myscene.sbx")
-
So my table that stores tile location and what model is on that tile there are 4182 records which means that's how many models there will be total on this 128x128, but as I said only 30-50 in camera view at any given time because of the top down view. I am not parenting anything. I simply loop through each record in this table, load the model, calculate the location based on center point of tile location and position the model there at load time. Here is a picture of one of the trees when I do show AABB in the model editor. Not sure how to read this as it has the outer orange line and outer blue line. I'm guessing the inner orange line is the actual AABB of the model and not sure what the other lines are. So did some tests but the issue still remains why does it say it's drawing so many entities if so few are actually visible. I did notice if I would move to one edge of the map the entities drawn number would go down. I have 746 trees and when they are just drawn I get 100 fps but it still says it's drawing all of them (15 were visible to camera) I have 240 bushes and when they are just drawn I get 140 fps but again it says drawing all of them (5 were visible to camera) I have 3196 grass and when they are just drawn I get about 30 fps and again it says it's drawing all of them (maybe 50 or so visible to camera) I tried switching the tree model to the LE tree model but it errors out on me. Guessing it's because I'm running it outside the editor and doesn't some of those have password stuff on them because they are from like Dexsoft or something? So I don't know how lights play into this all but if I remove all light sources in my scene it's much more reasonable and more accurate as to the number of entities the camera can see. So is this a bug of lights or just the reality of how LE works? I notice this in the editor also. This is exactly what I want, but with lights
-
These aren't static objects. You can cut trees down, pick grass, and pick bushes for food. They will go away when harvested. Players can plant trees, bushes, and grass on any tile they want. With the top down view only a certain amount of models will be visible at any one time. These also are not loaded with the scene. My scene is an empty terrain. The terrain is logically split into 1x1 tiles and I made a small program that randomly picked tiles for trees, grass, and bushes to be placed and stores that in a database table. I then load the scene, then loop through this database table to get the tile positions (which I then calculate their actual 3D position) and model name to load. I load them, then place them. This also won't just be for trees, grass, and bushes. You'll be able to build walls, floor tiles, chairs, beds, and other things that snap to this grid. You do give me something else to look at though. At one point I did parent them all to a pivot because I was thinking I could hide the pivot then override the hidden child entities to show them (which of course didn't work). I'll double check that I don't still have that pivot in there.
-
Did Josh ever say if LE3D or even LE2 would fix the ray radius issue because that seems like it could help in a situation like this.
-
128x128 with a grid size of 1x1 gives 16,384 tiles that could potentially have a tree, grass, or bush on it. All that information is stored in a sqlite table. I'll get the count in that table when I get home. I guess I didn't think 3800 was to high given how many tiles there are and the probability I gave for each tree, grass, bush to occupy a tile when generating the map. I'll double check the table count though when I get home just to make sure that matches. Some areas are heavier than others. I just moved my starting point to an open area and that's where I took the picture. I'll check the AABB of the models in the model viewer. Forgot to turn that on when I made those screenshots. The trees were larger and I did scale them down in UU3D so I would imagine the AABB gets scaled when I do that, but will double check that also when I get home. Thanks for the ideas guys.
-
So where does a person begin trying to figure out why frustum culling isn't filtering out the non visible models? Clackdor suggested trying the tree models that come with LE and I"ll do that tonight, but would seem odd if it was the models themselves.
-
Hey Clackdor, good idea. I'll do that tonight and see how it looks. Yeah I agree something is wrong it's just a giant pain to spend so much time on something like this. Frustrating.
-
Shouldn't Leadwerks be handling all this stuff for me? My models seem basic enough. Why would it be drawing everything if only a very small portion is visible on screen?
-
Even looping through just the surrounding tiles is a decent amount of looping and slows things down (I tried that already). With tiles being 1x1 it's a good amount of iterations. I think what I'll do is loop over that surrounding grid over multiple cycles so it splits things up some.
-
Something else seems to be going on per my other thread as it's drawing every object even though I can only see about 20 it looks like, but if nobody can figure out why that is what is the basic idea with what you are talking about Scott?