Jump to content
Ultra Engine Community

Josh

Developers
 View Profile  See their activity

  • Posts

    23,103

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh

    OnLive Lives?

    By Josh,

    When OnLive was first announced, I thought it couldn't ever work, because of latency issues. After my recent networking work, I think it might actually be feasible. We had fast enough response times that we could play lagless games with server-controlled physics, which is similar to the way OnLive works. A lot of our tests were performed with intercontinental connections, and of course those will have significant latency. We found that when playing within 1000 miles of the server latency was much less of an issue.
     
    I'm sort of interested from a consumer standpoint. If I can just pay a flat subscription fee and have access to a lot of games, that would be pretty appealing. There's a lot of games I would be interested in playing that I don't want to fork out $50 for. If I was paying to use them as part of a package of games, it would provide a lot more variety for your money.
     
    What do you think? Will OnLive change the face of gaming, or will it be a flop?
     

    http://www.youtube.com/watch?v=K6B4kAqkCZY&NR=1


  2. Josh

    Design Problem

    By Josh,

    I finished the collision editor, and now came across a pretty significant design issue. The approach the main editor has always taken is that by the time assets get into it, they are finished and ready for usage. Now I am making it so the model editor can change the structure of a model, save it, and have the main editor reload all instances of it. However, the Lua class scripts cause some problems with this. If I load a model with it's script enabled, the script might delete limbs fromt he model, replace them with other entities, or add new limbs. For example, the monster truck script frees the wheel meshes and creates vehicle wheels in their place. If this is allowed, then the tree view for the model will not be the same as what the GMF file originally contains. If the model is resaved, it will overwrite the existing GMF, and no longer contain the same limbs the script looks for.
     
    I could disable the class script in the model editor, but I also want to be able to view a finished model with the script enabled. For example, if I have a street light with an added corona, I want to be able to look at that in the nice big model editor window.
     
    Probably the best I can do is just leave it up to the end user not to do anything in the script that will break the model if it is resaved. Either that, or we have two separate applications built into the editor: a model viewer, which uses script, and a model editor, which disables the script.
     
    One kind of neat thing I did was set it up so the surface tree nodes only get populated when the user opens them. You might remember early versions of the model editor were slow to load large meshes because a ton of vertex data had to be turned into tree nodes. This will allow full display of all data, but it won't slow down loading. The worst that might happen is a brief pause when a surface node is opened. I'm planning to make all the data in each vertex editable, so you can clean up meshes by brute force, if you choose to. A few options like "Update Normals" will be available on a global and per-surface basis.
  3. Josh

    January 25, 2010

    By Josh,

    The networking code is pretty much done, but I don't think it's quite ready to release. We're redesigning the site to integrate the forum and community features together with the whole site, and an official documentation section is being created. In the meantime, I am going to start the model editor. This will be an app to replace the "Model Viewer" which will allow viewing and resaving of .gmf files. It will also include some editing features so you can adjust some of your meshes that might not have been converted or exported successfully. I'm planning for the app to be both integrated into the main editor, and compiled as a standalone app, the same way the script editor is. I'm also kicking around an idea for a GUI system.
  4. Josh

    XBox

    By Josh,

    Last week I was researching the XBox and PS3 platforms. An XBox version of Leadwerks is technically feasible, and though the cost is considerable, it's not a barrier we can't cross. However, obtaining the development license from Microsoft will be much harder. Basically, they are unlikely to sell a development license until this engine has gained more users and had a couple of commercial games released. So we'll just keep improving and building momentum, with the eventual goal of expanding to the consoles. Even if you can afford the licensing fees for your own game, you're not going to get an XBox development license without having already published another successful game. So it seems we need to first focus on the PC, and then spread out when we are ready. There's still the MacOS version coming, and possibly a Linux one, if the demand is there. The editor and tools will work on all three operating systems with no code changes.
  5. Josh

    Next up...

    By Josh,

    There sure is a lot to do around here!
     
    -Character animation example. I want to get the soldier model up and running with basic animations so everyone can use it.
    -Network improvements. I want to automate entity movement and some other features.
    -Scene graph improvements and vegetation collision.
    -Website and forum integration.
    -Revamping some of the tutorials.
     
    Watch the character movement in this video. I want to set up something simple like that so we can run around and have fun:


     
    Also need to get a new public demo out, but I won't release one until ATI fixes their cubemap bug! Apparently, the report has gone to the highest levels of AMD, and it is in the process of being fixed.
  6. Josh

    Apple Adopting OpenGL3

    By Josh,

    This is great news. I was a bit worried about the state of OpenGL on the Mac, since they presently only support version 2.1. With OpenGL3 support, we can have a uniform graphics API on Macintosh, Linux, Windows XP, Windows Vista, and Windows 7.
    http://www.theinquirer.net/inquirer/news/1585830/apple-slowly-opengl
  7. Josh

    Scenegraph Stuff

    By Josh,

    Discussing scene graphs in a game development or programming forum can be difficult, because I feel many people are very short-sighted about all the exceptions and complications that can arise in a flexible environment. In fact, there are many situations that will make rendering with a scene graph much slower than without. Many programmers have a tendency to ignore anticipated problems and assume it will work itself out somehow. It's also very hard to predict how bottlenecks will form and what "typical" behavior in a game will turn out to be. Thus, in the past I have never gotten much out of all the discussions and theories that exist on this subject.
     
    The primary complication arises from the fact that some objects are typically static, while others may move around. Static objects are infrequently added to or removed from the scene graph, so quad trees or octrees work great. Dynamic objects do not work well with these approaches because of the amount of data that has to be recalculated.
     
    Another problem appears when an object crosses over the bounds of two "cells" or areas. If an object lies on an edge where it overlaps two areas, what should you do? Recalculating the bounding box of the area is one solution. Consider a quad tree with three branches. If a car in one leaf moves, the branches two levels up have to have their AABB recalculated. If the leaf contains a large number of objects, it may require iterating through all of them to recalculate the AABB. So this solution isn't very good for a scene with a lot of moving objects. This approach, incidentally, is the one used internally by the vegetation system.
     
    Another approach is to list the object in both areas. However, if you have a large building that may occupy dozens of separate areas at once, this approach can create a lot of unnecessary overhead.
     
    Before I discuss my solution, let's consider the fundamental differences between static and dynamic objects in a scene. Static objects are usually used for trees, grass, plants, buildings, fences, and other repetitive objects. They tend to be very high in density and quantity. Dynamics objects have an overall tendency to be more spread out and fewer. An area might be littered with a lot of physically interactive debris, but that's still less than the tens or even hundreds of thousands of trees that might exist. This means the two kinds of objects have fundamental differences in distribution that makes different scenegraph systems more optimal for either.
     
    For static objects, the quad tree approach with adjusting bounding boxes is fantastic. For dynamic objects, it makes more sense in practice to have a nonrecursive grid with adjusting bounding boxes. It's pointless to have recursive levels of bounding box adjustment and culling when the quantity of dynamic objects is nowhere near that of the vegetation system, which benefits from a heavy optimization system. The renderer can just grab a square of sectors within the camera range, in the same way the terrain renderer does, as this pseudo code shows:

    for x=camera.position.x - camera.range to camera.position.x + camera.range { for z=camera.position.z - camera.range to camera.position.z + camera.range { if !sector:Culled(camera) { sector[x,z]:Draw(camera) } } }
    This also is optimal for AI and other updating. The S.T.A.L.K.E.R. engine has a setting for AI range. This is how they are able to have so many characters in the world, and only have to worry about updating the ones in the near vicinity. I might add an "update range" setting so that only models within a certain distance have their Update callbacks and script functions run. The code to do this would look something like this:

    for x=camera.position.x - camera.range to camera.position.x + camera.range { for z=camera.position.z - camera.range to camera.position.z + camera.range { sector[x,z]:Update() } }
    These are some small improvements I plan to make. The effects won't be immediately apparent to most people, but they will ensure your project will stay fast as your work becomes more advanced.
  9. Josh
    We're finishing up 2009 by resolving some longstanding design issues that haven't been particularly critical, but have weighted on my mind. Framework is not like the main engine. It's far more high-level, and is also the kind of code people want to customize. I don't like locking the user into my way of doing things. However, the interaction between Lua, C++, and Framework commands are a real issue, which we started to see immediately as Lua became available. This was resolved by compiling Framework into the engine DLL and providing the source code in the BMX folder. Most people will be happy with the default settings, but a few will want to write their own renderers, and fortunately they still can. Most importantly, Lua can access the Framework commands, so all the water and atmospheric effects will work the same in C++ and in the editor. In the end, we finally wound up doing something I said we never would: There are commands like SetBloom(), SetNearDOF(), etc. However, since this is open-source code built on top of the buffer and shader systems, I am happy with it. The user still has low-level power, but is supported by a lot of default code that does most of what they want. This is the design I have always tried to provide.
     
    The solution we arrived at with Framework can also be applied to other systems that are commonly needed, yet don't quite fit into the main engine. Providing open-source code, and then compiling it into the DLL and adding a Lua interface seems to be a good solution for anything like this. The next system I could see handled this way is AI. I am carefully watching the work Chris Paulson is doing with the recast library, and I think it has a very promising future.
     
    Oh, and in other news Penumbra is finally available on Steam! Penumbra is a physics-driven game that uses the same physics library we use, Newton Game Dynamics. I highly recommend this series, both for learning and for fun.
  10. Josh

    Merry Christmas!

    By Josh,

    There's a crazy sale on Steam right now. If you haven't played STALKER yet, you can get it for $10:
    http://store.steampo...check/app/4500/
     
    In other news...
     
    Framework is being compiled into the engine DLL and being made an official part of the engine API. It will remain a separate piece of code for BlitzMax programmers they can just import. A mechanism will be added to add your own custom post-processing effects, though this will not be available immediately. It will be something like this:

    CreateEffect( callback ) EnableEffect() DisableEffect() FreeEffect( effect )
     
    If you prefer to use the existing C++ code you are free to do so. However, the integrated framework code will allow Lua to access the Framework commands, so your scenes will work seamlessly between the editor and any programming language you choose. The whole design of our buffer/shader system and framework makes a heck of a lot of sense now. It just had to be allowed to evolve so we could determine the best solution. You've got an the easy-to-use framework commands, but still have the low-level buffer and shader stuff which can be used to do many things.
     
    The Lua command set is also slowly being exposed. At first, it will just have the bare minimum commands you need to set the variable "fw" to the framework object you create in your program. In time the entire Lua API will be exposed through the DLL. This will allow limitless extensibility for whatever you want to do with Lua. You can expose your own C++ or other functions and classes, or do whatever you want.
  11. Josh

    12-18-2009

    By Josh,

    This is a good idea to keep in mind, especially with something like software development:
     
    "Don't judge each day by the harvest you reap but by the seeds that you plant."
    -Robert Louis Stevenson
  13. Josh

    December 7, 2009

    By Josh,

    It's 12:30 in the morning, but I have the model scripts working the way I want. Thanks to "Nilium" for his tips, and to everyone who gave their feedback. I am confident in this revision. I have a lot of scripts that need to be slightly altered, but it's just a matter of adjusting the function structure, not really changing any existing code.
     
    Here's the light_ambient script:

    require("scripts/class") require("scripts/linkedlist") local class=CreateClass(...) function class:Spawn(model) local object=self.super:Spawn(model) function object:Update() AmbientLight(self.model.color) end function object:SetKey(key,value) if key=="color" then local returnvalue=self.super:SetKey(key,value) self:Update() return returnvalue elseif key=="intensity" then local returnvalue=self.super:SetKey(key,value) self:Update() return returnvalue else return self.super:SetKey(key,value) end return 1 end function object:Kill(model) local model,object --Iterate through all instances of this class. --If any instances are found, use them to set --the ambient light value. for model,object in pairs(self.class.instances) do if object~=self then object:Update() break end end self.super:Kill() end object.model:SetKey("intensity","0.5") --Call the update function before finishing. --This can only be called after the function is declared. --We don't actually need to call it here since setting the intensity key --will do that for us, but it's still a good idea as a general rule. object:Update() end function class:Cleanup() --Restore default ambient light setting. AmbientLight(Vec3(0.5,0.5,0.5)) self.super:Cleanup() end
  14. Josh

    12-17-2009

    By Josh,

    Well, the single-state lua update is out and I am ready to start making tutorials again.
     
    Someone in the forum pointed out the game Fuel to me. This is an offroad racing game with a nearly infinite world. The data is streamed off the hard drive, basically like its treating the drive as if it were extended RAM. The game got bad reviews, but I think it's great. I went driving for at least 30 minutes and covered mountains, desert, redwood forests, and ravines. I'm in love with the terrain engine. If only they had used that to make S.T.A.L.K.E.R...
     
    There's much to do with our existing technology before I start inventing new technology again, but the possibilities are intriguing.
  17. Josh

    Lua work

    By Josh,

    I've been revising the Lua design a bit. Ideally this should have been done six months ago, but I did not realize how popular it would be. During beta testing there wasn't much interest in it. That's understandable, because no one likes using beta software. As soon as it was released, suddenly there was some very advanced stuff being implemented immediately. This is great, and I can see my thoughts about how it would benefit us were correct. It also made me want to implement a single-state system so that we could really use Lua to its full potential. I spent all day on it, and I think it's done. I just have to finish making the changes to the class scripts. This wasn't my ideal way to develop, but if changes are to be made, they should be made now, not in three months.
  18. Josh

    Week 2

    By Josh,

    People are starting to use Lua, which is good. Initially there was some confusing, but in each case it turned out to be a small misunderstanding. I spent a few hours editing the wiki to add Lua syntax to the commands. I'm going to start working on Lua demos and more high-level stuff, in addition to fixing any bugs that exist. I'm not too interested in adding new features right now. This engine has plenty of features. Tons. It's time to use them to make something.
  20. Josh

    The Day After

    By Josh,

    I'm taking a short break before I swap GPUs to fix that ATI shader error.
     
    There are now 110 Leadwerks Engine 2.3 users. I did not think the number would be nearly that many.
     
    I am most interested now in documentation, tutorials, and examples as well as improving existing features. With C++, it wasn't worth diving too deep into game tutorials, because only 40% of the programmers would find it useful. Furthermore, it is harder to design useful game components that are easy for users to learn from. With Lua, I don't feel like I am wasting my time. Everyone can understand Lua, and even if the code gets turned into a compiled C++ program, it still gives all programmers a starting point they can learn from. It also gives us a common language we can talk to each other in and share scripts.
     
    I'd still recommend C++ or BlitzMax if you know what you want to make, and have high performance demands. But I think Lua is fantastic for smaller games, prototyping ideas, and learning.
  21. Josh

    Entering data...

    By Josh,

    I did not expect this many upgrades over the weekend! I'm entering data as fast as I can.
     
    Already I can see the private sections are a big improvement. It totally changes the feel of the forum. It feels like it's more our own area, instead of just a random bulletin board floating around in cyberspace. If that makes any sense.
  22. Josh
    Previously I wrote about introducing latency to the voxel cone step tracing realtime global illumination system. The idea here is to improve performance and quality, at the cost of a small delay when the GI calculation gets updated. The diffuse GI lighting gets cached so the final scene render is very fast.
    Here's what a gradual GI update does. Of course, this will be running unseen in the background for the final version, but this shows what is actually happening:

    My new video project1.mp4 Vulkan has a sophisticated system for supporting multiple device queues. I initially thought I could just run the GI update on a separate queue, like a low-priority CPU thread running in the background:

    Unfortunately, this is not really possible on today's hardware. Even with the lowest queue priority setting, the GI queue hogs the whole GPU and causes the rendering queue to stall out. So I had to stick with doing everything in the main render queue.
    The GI calculation only updates when the camera moves a certain distance. There is a latency setting that controls how many substeps the task is broken up into. High latency means many small steps, so the framerate will not dip much when GI is updating. Low latency means the GI will significantly decrease the framerate every time the camera triggers an update. It is possible to set up a combination of high resolution and low latency that will cause the render queue to stall out. If this happens the program will encounter a VK_ERROR_DEVICE_LOST error. I don't know how to prevent this for now, other than just don't use ridiculous settings.
    Here you can see the GI updating seamlessly as the camera moves around. I actually have to use three sets of volume textures, one for rasterization and direct lighting, and then the final GI data is stored in a set of two textures that alternate back and forth. This allows me to display the previous results while the next update is still processing, and the two textures get swapped when the update is finished.

    962180265_Mynewvideoproject1.mp4 A couple of small issues remain.
    The transition between textures needs to be smoothed, to handle changes to the environment. I need a way to calculate the diffuse GI for dynamic objects that don't appear in the GI reflections. (I have an idea.) The items are not too terribly difficult and they will be done in short order. I'm very happy with how this has turned out. It provides quality real-time global illumination without compromising performance, and it will work very well with VR.
  23. Josh

    Sparse Voxel Octree Reflections

    By Josh,


    Articles
    I've now got basic specular reflections working with the sparse voxel octree system. This uses much less memory than a voxel grid or even a compressed volume texture. It also supports faster optimized ray tests, for higher quality reflections and higher resolution. Some of the images in this article were not possible to produce in my initial implementation that used volume textures.
    This shot shows the reflection of just the diffuse color. Notice the red column is visible in three reflections, but not in the reflected floor. It would be possible to add a secondary bounce to add reflections in reflections:

    With direct lighting added to the reflection, and the resolution turned up a bit, we can see the ray tracing is getting quite detailed. Of course, we prefer to use blurred downsampled data for voxel ray tracing, but the results so far indicate there is enough data to produce a good final result:

    In the shot below we are using a voxel size of about three centimeters, in a 1024x1024x1024 sparse voxel octree. A simple voxel grid would require 32 GB of video memory, but our structure fits into less than 240 MB.

    Turning the reflectivity up for all materials doesn't really look good and creates a confusing look, but it's still interesting to see. The amount of detail we see in the voxel reflections is quite good. The voxels are so high resolution we can even see the texture details of the original polygon mesh!


    The speed of the octree traversal routine is very important here, and I am in contact with some university faculty to see about implementing something special to give you the maximum possible performance.
    The next step is to downsample the octree data to display blurrier reflections. This will also be used for calculating GI.
  24. Josh

    Ultra App Kit Beta Updated

    By Josh,


    Articles
    An update is available for the Ultra App Kit beta on Steam.
    Menu open / close behavior is finished and is now working bug-free. Fixed problem where list boxes were only showing the first item. A submenu item is demonstrated in the example program. A progress bar widget is added in the example program. A label widget is added in the example program. A second radio button is added in the example program. Still to do:
    Work out some scaling issues. Light theme. Some small details with some widget styles. Finish documentation. Project wizard / manager application.
  25. Josh

    GUI Work

    By Josh,


    Articles
    The terrain streaming / planet rendering stuff was the last of the feature creep. That finishes out the features I have planned for the first release of the new engine. My approach for development has been to go very broad so I could get a handle on how all the features work together, solve the hard problems, and then fill in the details when convenient.
    The hard problems are all solved so now it's just a matter of finishing things, Consequently, I don't think my blogs are going to make any more groundbreaking feature announcements, but rather are going to show steady improvement of each subsystem as we progress towards a finished product.
    The GUI is something I wanted to spend some more cycles on. The initial release of the new engine will be a pure programming SDK with GUI support, but the GUI I am implementing is also going to be the basis of the new editor, when that time comes. I decided that using Lua scripts to control widgets was a bad idea because when operating at-scale I think this will cause some small slowdown in the UI. My goals for the new editor are for it to load fast and be very snappy and responsive, and that is my highest priority. It is nice to have overarching design goals because then you know what you must do.
    I've started the process of converting our Lua widget scripts into C++ code. The API now has functions like CreatePanel(), CreateButton(), etc. and is much more formalized than the flexible-but-open-ended GUI system in Leadwerks 4. For customization, I am implementing a color system. We have a bunch of color constants like this:
        enum WidgetColor     {         WIDGET_COLOR_BACKGROUND,         WIDGET_COLOR_BORDER,         WIDGET_COLOR_FOREGROUND,         WIDGET_COLOR_SELECTION,         WIDGET_COLOR_HIGHLIGHT,         WIDGET_COLOR_AUX0,         WIDGET_COLOR_AUX1,         WIDGET_COLOR_AUX2,         WIDGET_COLOR_AUX3,     }; There is a Widget::SetColor() command that lets you set any of the above values. Now, this is not a complete set of colors. The GUI system uses a lot more colors than that. But these colors are generated by multiplying the defined color by some value to make it a little darker or a little lighter.
    This means I am making a decision to reduce the flexibility of the system in favor of more formalized feature support, better documentation, and better performance.
    I think we will be able to load a color scheme from a JSON file and that will allow enough customization that most things people want to do will be possible. For custom widget behavior, I think either an actor or a DLL plugin could be used. There are enough options for future extensibility that I feel like we will be okay deferring that decision for now, and I am not coding myself into a corner.
    Here's a shot of the current state of things:

    I probably have enough GUI code ahead of me I could just go silent for a month and stay busy with this. I don't really want to think about that for the rest of today. Goodnight.
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...