Jump to content

Josh

Staff
  • Content Count

    15,717
  • Joined

  • Last visited

Everything posted by Josh

  1. This conversation right here shows something important. In my quest to make things easy I am trying to simplify complicated things, but this is actually making things harder. Sometimes complicated things are complicated and just have to be explained. Little Timmy may not understand the explanation, but @TheConceptBoy will, even if he has to read it a few times before it makes sense. It would be better to expose the animation stack system even though some people won't understand it, than to say "no, it is too hard for you". I think my experience with Vulkan is affecting my thinking. It was a harsh mistress, but it's such an absolutely zero-bullshit API and eliminates so much ambiguity that OpenGL had. Maybe "well-defined complexity" is something I should give more consideration to.
  2. Josh

    Evolution

    I feel like a lot of what I wrote above is just us acknowledging what we are and not trying to be something different. I want this to be more of an advanced technology company.
  3. Josh

    Evolution

    I think this is the right idea and your expectations are realistic. A strictly defined API that exposes the editor internal structure to Lua, similar to MaxScript in 3ds max, would be very useful.
  4. Turbo Game Engine is due out in 2020. i think the biggest question is what would the commands look like that the user interfaces with? How would your code automatically choose the right monitor to use? What do you think about this?
  5. Data for this is rare, but the best estimate I can find is that one-half of one percent of users have multiple monitors: https://www.pcgamer.com/poll-do-you-use-more-than-one-monitor/ That said, I am interested in supporting this in the new engine, as developers tend to be a stranger bunch than the average PC gamer.
  6. Josh

    Evolution

    This is a good time to write about some very broad changes I expect to come about over the next year in our community as our new engine "Turbo" arrives. Turbo Game Engine, as the name suggests, offers really fast performance using a groundbreaking Vulkan-based renderer, which is relevant to everyone but particularly beneficial for VR developers who struggle to keep their framerates up using conventional game engines. I want to help get you onboard with some of the ideas that I myself am processing. Less emphasis on how-to tutorials, more emphasis on API documentation The new engine assumes you are either an artist or a programmer, and if you are a programmer you already know basic C++ or Lua. More attention will be paid to precisely documenting how commands behave. There will be a more strict division between supported and unsupported features. There will be less "guessing" what the user is trying to do, and more formal documentation saying "if you do X then Y will occur". For example, every entity creation function requires the world object be explicitly supplied in the creation command, instead of hiding this away in a global state. There will not be tutorials explaining what a variable is or teaching basic programming concepts. More responsiveness to user requests, especially for programming features Leadwerks 4 features have been in a semi-frozen state for a while now. Although many new features have been added, I have not wanted to create breaking changes, and have been reluctant to introduce things that might create new bugs, because I knew an entire new infrastructure for future development was on the way. With the new engine I will be more receptive to suggestions that make the engine better. One example would be an animation events system that lets users set a point in an animation where an event is called. These changes need to be implemented within the design philosophy of the new engine. For example, I would use an Actor class method to call the event function rather than a raw pointer. Emphasis should be placed on what is practical and useful for competent programmers and artists, and how everything fits into the overall design. Less attempts at hand-holding for new developers The new engine will not attempt to teach children to make their own MMORPG. Our marketing materials will not even suggest this is possible. The new engine will deliver performance faster than any other game engine in the world, period. Consequently, I think the community will gain a lot more advanced users, and though some of them will not even interact on the forum I do think you will see more organic creativity and quality. In its own way, the new engine actually is quite a lot easier to work with, but the sales pitch is not going to emphasize that, it will just be something people discover as they use it. I love seeing all the weird and cool creations that comes from people who are completely new to game development, but those people were new to game development and did well with Leadwerks had a lot of natural talent. Instead of trying to come up with a magic combination of features and tutorials to turn novices into John Carmack, we are going to rely on the product benefits to draw them and expect them to get up to speed quickly. Discussions should be about what is best for intermediate / experts, not trying to figure out what beginners want. Ease of use is subjective and I feel we have hit the point of diminishing returns chasing after this. If beginners want to jump in and learn that is great, but it is not our reason for existing. Stronger focus on the core essentials At the time of this writing, there are only eight entity types in the beta of the new engine. We can't win based on number of features, but we can do the core essentials much better than anyone else. Our new Vulkan renderer offers performance that developers (especially VR) can't live without. Models, lights, and rendering are the core features I want to focus on, and these can be expanded by the end user to create their own. For example, a custom particle system with support for all kinds of behaviors could easily be created with the model class and a few custom shaders, without breaking the performance that makes this engine valuable. Our new technology is very well thought out and will give us a stable base for a long time. I am planning on a plugin / extensions system because its best for this to be integrated in the core design, but you should not expect this to be very useful for a couple of years. Plugin systems require huge network effects to offer anything valuable. We can only reach that type of scale by offering something else unique that no one can match us on. Fortunately, we have something. It's right in the name. More formal support for good standards Vulkan has turned out to be a very good move. I don’t think anyone realizes how big a deal GLTF support is yet: you can download thousands of models from Sketchfab and other sources and load them right now with no adjustments. I may join the Khronos consortium and I have some ideas for additional useful GLTF extensions. I'm using JSON for a lot of files and it's great. DDS will be our main texture file format. There are more good standards today than there were ten years ago, and I will adopt the ones that fit our goals. Different type of new user appearing With Leadwerks, the average new user appears on the forum and says “hey, I want to make a game but I don’t really know how, please tell me what I need to know.” With the new engine I think it will be more like “hey, I’m more or less an expert already, I know exactly what I want to make, please tell me what I need to know.” I expect them to have less tolerance for bugs, undefined behavior, or undocumented features, and at the same time I think it will be easier to have frank discussions about exactly what developers need. In very general terms that is how I want to focus things. I think everyone here will adjust to this more strict and well-defined approach and end up liking it a lot better.
  7. I’m using a ray, not a geometric volume. Different math although it looks similar to a skinny cylinder. The really interesting part is that although the line has no thickness and would be invisible (or nearly) in a perfect reflection, the surface adds vertical height to the reflection, the same way light reflections appear impossible tall on a rainy street.
  8. The slow step tends to be lights (especially point lights) that get redrawn each frame.
  9. I assume the link was in the table of contents, which is now fixed. Thanks!
  10. Yes. The voxel raytracing system will hopefully handle this.
  11. A new update is available for beta subscribers. What's new Added support for strip lights. To create these just call CreateLight(world, LIGHT_STRIP). The entity scale on the Z axis will determine the length of the line, and the outer range will determine the radius in which light shows. Added new properties to the JSON material scheme. "textureScroll" is a float value that can animate a texture to make it smoothly move. "textureScrollRotation" is an angle to control which direction the texture moves. An example material is included. Renamed "albedoMap", "normalMap", "emissionMap", "displacementMap", and "brdfMap" to "baseTexture", "normalTexture", "emissionTexture", "displacementTexture", and "brdfTexture" in JSON material scheme.
  12. One issue with this type of technique is it does not work very well with shadows. It could be possible to add shadowmaps for some shapes, but since light is coming from multiple directions it would look odd, and it would be impossible to correctly shade the specular component, because it can come from many different directions. I think the voxel raytrace system I have in mind will be able to handle these types of things better. But, this is another tool you can access. What really prompted this was @reepblue showed me his test level and I thought the fluorescent tubes should get a new light type for them.
  13. @m.yuneeb90 That's exactly what I did, although the example you posted above does not show any specular reflection for the line strips. Getting a specular reflection with a line is actually really hard because there isn't an easy intersection / closest point algorithm and you have to mess around with plane equations. Other shapes are fairly easy so I think those can be added too without much trouble.
  14. I have seen many different definitions of what an "area light" is. What are you describing?
  15. This light is a geometric shape and has nothing to do with the visual model. It's like a light saber. I support it would be more accurate to create one strip light for each light tube and leave a small gap between them.
  16. Debug mode has a lot of checks for errors, and STL especially has a ton of checks to make sure you aren't doing something wrong. It should only be used for development, never released to the player. You can multiply any time-dependent values by Time:GetSpeed() to make your game run at the same speed regardless of framerate.
  17. I got a new light type implemented in the Vulkan renderer. Very impressive, I will show it off soon.

    1. wadaltmon

      wadaltmon

      Does it relate to luminescent objects? i.e. not a point light or a directional light, but say for instance a lightsaber - a long strip that emanates light from all points on it equally

  18. It's always fun when I can do something completely new that people have never seen in a game engine. I've had the idea for a while to create a new light type for light strips, and I got to implement this today. The new engine has taken a tremendous amount of effort to get working over two years, but as development continues I think I will become much more responsive to your suggestions since we have a very strong foundation to build on now. Using this test scene provided by @reepblue you can see how this new light type looks and behaves. They are great for placing along walls, but what really made me interested was the idea to calculate specular lighting not from a single point, but with a different way. I thought if I could figure out the math I would get a realistic reflection on the ground, and it worked! The reflection on the floor is actually the specular component of the light. We are used to thinking of specular reflections as a little white circle that moves around, but the light doesn't have to be coming from a single point. Some calculations in the shader can be used to determine the closest point to the light strip and use that for reflections. The net effect is that a long bar appears on the floor, matching the length of the light. This is not a screen-space effect or a cubemap. When you look down at the floor the specular component is still there shining back at you. Every surface is using the same exact equation, but it appears very different on the walls, the ceiling, and the floor due to the different angles. Even a surface facing opposite the light will correctly reflect it back to the camera. In this image, I created a small green strip light that looks like a laser. There is no visible laser beam, but if there was it would appear above the soft green lighting. The hard line on the ground is actually the specular reflection of the light. You can see it reflecting off the sphere as well. The new Vulkan renderer also supports box lights, which are a directional light with a defined boundary, and I have an idea for one more type of light.
  19. Ah, I see. You are the expert.
  20. It looks very good but there isn't much variation in color or other properties. It looks like just a really nice normal map with a plain metal texture on top. IMO the little details should be gold or silver, and there should be more variation.
  21. I think so. People requested the C++ class stuff rather than raw pointers. The problem with having a "current" animation and frame is that there isn't really one. The animation system may have a dozen different animations it is blending in between. It may have multiple copies of the same sequence it is blending in between. In the future I think adding an animation event feature to call a class method when a specific frame is crossed would be a good idea. That is basically what the EndAnimation() method does, but it only occurs at one position.
  22. There is a method in the Actor class that will be called automatically. This works in either C++ or Lua.
  23. I think the text import actually does something like that. I have not used it in a long time, I will have to check...
  24. A single image is best for speed because it only requires one texture lookup, and these are a moderately expensive operation. It also reduces you video memory usage, by four times.
×
×
  • Create New...