gamecreator

Hey, I just saw your post. May be a silly question but which file are you modifying? I don't have anything that looks like your original shader. I thought it might be the bloom.shader file in the Shaders\PostEffects\Utility folder. It has a section that looks close but different: I tried replacing it anyway with your version but it didn't work for me.

Unfortunately, there are two problems with the documentation: 1. It is incomplete. The last several updates, especially, are rather lacking (i.e.: there are zero GUI examples for C++). And many functions that are in the documentation don't have examples. Some are straightforward and honestly don't need it, others aren't. 2. Some functions are intentionally undocumented because they're unofficial. I think this is the case for the above function(s). However, as far as I can tell, there is no way to know if a function is undocumented because Josh forgot to/chose not to document it or that it's really unofficial.

You can use world:GetEntity() to get each one. There's an example using it here: https://www.leadwerks.com/community/blogs/entry/1866-common-bottlenecks/page/2/?tab=comments#comment-8055

Things don't have to be complicated to be functional. How many functions you create and how many arguments they have are in your hands. Though I'm sure someone will be happy to create a wrapper. Edit: you could also have a visual GUI designer but I know that's pushing it.

This is what Borderlands 3 does. It's a good system.

Sadly, I don't think there are options to help with this. I hope I'm wrong but I believe the brush size is limited to the maximum slider size and the terrain view distance can't be increased. I tried to see how fast I can paint a flat 4096x4096 terrain and it took me several minutes to awkwardly fly around and paint, area by area, sometimes not being sure what areas I've already covered (since you can't see all of the terrain). This is after I sped everything up to maximum under Tools menu, Options, Viewports, Camera section and I held the Shift key to move around as fast as possible. Working with this map size is very difficult. That said, consider that perhaps your map size may be too large. I remember Jen thought that she would need a huge map and I think she said 512x512 was still too large for her project, after some further thought. Consider putting some temporary landmarks at the edges of the map and see how long it takes you to get there with reasonable speed, even in a vehicle.

I think this is the situation with everything it does. It does an OK job estimating (and much better than just upscaling) but it can't make up for all missing details. The arch and your original image were blurry too; obviously the original images would be much more crisp and detailed. That said, this might still be helpful if you already have a 1024x1024 image and you want to make it 2048x2048, or from there to 4092. I suspect the more detail it already has to work with, the better it'll do.

Curious how it would do with this grass texture: This is the original (from here) Of course, the next natural question is how it does with upsizing seamless textures. In other words, does it introduce seams?

It still has a long ways to go but it's definitely an improvement of just resizing up. I would encourage you to get a true, crisp, 2048x2048 (or any dimension large image), downsize it, then use the downsized version to scale up. Then compare your results to the original 2048x2048 texture.

Hmmm. Here's what generate convex hull creates for a test scene: And here's what convex hull in the model editor creates: Edit: it seems like that for the model editor, Josh removed the consideration for multiple children and treats the entire model as one.

It seems to do something similar but gives different results than the options in the model editor. I'm a little confused. ?

Neat trick. Thank you for sharing and the nice, detailed presentation!

There is that question too. I thought we were talking about free, hobby projects.

Agreed. That's the ideal situation. I think it makes sense too for the project to be small enough that one person should be coding and likely the same person directing everything. Once you found a leader/coder the rest should be map designers, artists, musicians, sound, etc. It's also very important to keep things moving. You can't wait two weeks for someone to maybe finish something.

Oh, like a game HUD. I would do that with a combination of drawimage and drawtext and the function that gets screen coordinates from 3D coordinates. I forget its name and I can't find it in the docs right now. Edit: found it: camera->project()

I definitely will.

I'm not clear what you're looking to do. Are you trying to add a label to it by code, looking for the proper coordinates to position it? Or can you just add it by editing the model?

I'm curious about your process and what collapsing models improves. Maybe you could either blog or post elsewhere about it. In the meantime, I think the collisionmesh bug remains.

Collapsing it combines all of the meshes into 1... and eliminates the physics shapes. ?

I should have been more clear that they're four individual models I created in 3DS Max. By collapsing do you mean combining into one? I could certainly combine the ground and the sphere but the idea is to have two separate collision types in one scene and that can't be done with one model (you need at least one named collisionhull and at least one named collisionmesh). Since I use physics debug, I think I could have simplified this by not even having visible models, just the collision meshes.

I have the following scene with a ground and a ball (together in one fbx/mdl but four separate models: ground, ground collision shape, sphere, sphere collision shape) and a code-generated character controller. The ground and the ball have their own collision shapes. If they're both collisionhull, everything is fine. However, if either one is a collisionmesh, the controller falls through the ground, even though the camera physics debug (and the model editor) shows that the collision meshes are there. Below is the code and attached is the Models folder with all of the fbx and mdl files. #include "Leadwerks.h" using namespace Leadwerks; Entity* player = NULL; int main(int argc, const char *argv[]) { Leadwerks::Window* window = Leadwerks::Window::Create(); Context* context = Context::Create(window); World* world = World::Create(); Camera* camera = Camera::Create(); camera->SetRotation(25, 0, 0); camera->Move(0, 0, -16); camera->SetDebugPhysicsMode(true); Light* light = DirectionalLight::Create(); light->SetRotation(35, 35, 0); Model* scene = Model::Load("Models/scene_bothcollisionhull.mdl"); // This works! // Model* scene = Model::Load("Models/scene_bothcollisionmesh.mdl"); // This doesn't work - controller falls through ground // Model* scene = Model::Load("Models/scene_groundcollisionmesh_spherecollisionhull.mdl"); // This doesn't work - controller falls through ground // Model* scene = Model::Load("Models/scene_groundcollisionhull_spherecollisionmesh.mdl"); // This doesn't work - controller falls through ground // The next 3 lines don't seem to be necessary but I tried them anyway // scene->SetMass(0); // scene->SetPhysicsMode(Entity::RigidBodyPhysics); // scene->SetCollisionType(Collision::Scene); //Create a character player = Pivot::Create(); Entity* visiblecapsule = Model::Cylinder(16, player); visiblecapsule->SetScale(1, 2, 1); visiblecapsule->SetPosition(0, 1, 0); player->SetMass(1); player->SetPhysicsMode(Entity::CharacterPhysics); player->SetPosition(0, 1, 0); while(true) { if(window->Closed() || window->KeyDown(Key::Escape)) return false; Leadwerks::Time::Update(); float move = (window->KeyDown(Key::Up) - window->KeyDown(Key::Down)) * 4; float strafe = (window->KeyDown(Key::Right) - window->KeyDown(Key::Left)) * 4; player->SetInput(0, move, strafe); world->Update(); world->Render(); context->Sync(); } return 0; } Comment out one of the Model::Load lines and uncomment another one to load a different combination. Models.zip

https://graphicsgale.com/us/ is another good one for pixel art (also free).

God I hope this is a tip in one of the new tutorials (maybe in an optimization one) because I'm sure I'll forget this.

Leadwerks 5 will be "exclusively 64-bit," for what that's worth. I didn't find any news on 4 and since I know Josh is eager to move on, I doubt he'll implement it there.

This system makes sense on several levels. For one, if it truly is the last engine Josh will ever write, this will cement that further, while 5 implies that there will be a 6. Next, the yearly paid updates will also jive well with the yearly labeling. That said, I'm far more concerned about the new features than the label.