Michael_J

It would be nice to be able to assign a light a specific group ID. Setting a model's "IgnoreLightGroup" value would cause it not to be affected by any lights with that group ID. Proposed Behavior: --By default all lights and models are assigned to group 0, which allows all lights to affect all models. --Setting a light to, say, group ID 1 would still affect all models UNLESS a model was also set to "ignore" group ID 1. --The ability to set multiple "ignore" ID's to a model is preferred, but not mandatory. Why is this important? Not only is it a way to optimize your scene (so that you're not casting needless shadows from lights that would never have any affect anyway) it's also a good way to correct certain situations, such as: Let's say you have a light being triggered by a lightening flash (just as an example). If your player was running on older hardware you may have an option so that VFX lights do not cast shadows. Now, let's say your player is inside a house looking out. Normally, without casting shadows, if the lightening light was triggered then everything would be affected by it--house interior and exterior alike. BUT, if the house interior was its own model(s), and it was assigned to "ignore" the group ID of the lightening light, then it would not be affected (which would look more proper in this situation). I know you can turn lights on and off and set ranges, but there's instances where this won't work, such as the case above where you still need to see what's going on outside of the house and a light is "all encompassing".

Cheers. Thanks for that It's quite a nice change from hardcore racing sims where I didn't have any creative license--the tracks had to look precise, the cars had to look precise, etc., etc. With this--it's my world and I can do what I want

A little Rogue System engine integration WIP video. Nothing fancy--just showing the basic functions so far...

The easiest way I know of to avoid screen tear is to enable v-sync edit: My bad--saw that you have v-sync enabled. That SHOULD do the trick...

Yeah, it's the only mode I use in 3DS MAX--very intuitive...

Sorry if this is already available (or if it's already been mentioned)--if it is I can't easily find it. If not... It'd be nice to have an option to change the editor's current camera rotation method--pivoting about the centroid of the camera--to allow it to orbit around the selected object. Thanks...

In the assets tab you can right click on folders and get a menu of basic options (copy, paste, etc). It would be EXCELLENT if you could add an option for the editor to ignore that folder from auto-converting files (maybe "Ignore" with a check mark when selected, or something like that). For example, I have working folders where I put PSDs, WIP tga's and FBX's, etc. These don't need to be converted, and often times the files that are generated clutter up the folder. Not a big deal, just something to keep working folders clean... Thanks

no DOF--I texture/map by using more detail where the camera will be, and less where it won't. This usually offers a DOF-like effect. Right now they're just Diffuse+norm+spec. The spec and normal maps were done in about 1 minute each, so they're not very defined yet. Basically just making sure everything works right now Thanks...

"This does show the importance on us developers side to create frameworks for our game logic that is a layer above the engine we use" I did this very thing with RogSys, which is partly the reason why I have the engine almost fully integrated after only a month. There's still specific things to do and lots of bug testing still, but the bulk of the work is done. A layer of separation between the engine and the game code is never a bad thing--it allows you to be flexible. As for Josh's stance--beyond the fact this is his baby and he can raise it as he see's fit, we all known the gaming industry is constantly in a state of flux. Not long ago the PC was "dead" (as it's been many times before), and is now on the rise again. You have to be prepared to move with the trends if you want to keep going and growing Add to this the other reasons he mentioned and it's not hard to see why he's making the choices he is....

Here's a quick shot showing a single example of how docked ships get loaded and positioned at the docking stall they were last recorded as being at. Obviously missing lots of art--in the process of converting files now. But, you get the idea

Hi all, Although I have forums for RogSys where I typically post development updates, I thought I'd start a blog here that covers the Leadwerks-specific aspects of it. Maybe someone will find an odd bit of information here and there that might be useful. For this first entry I'll give you a bit of history on what brought me to Leadwerks, and how the first month of engine integration has gone. A casual warning: I'm typing on the fly and I don't have much edit time, so you'll excuse any fairly blatant typos An engine change was not something I'd planned on AT ALL. I spent several months trying out different engines early on in order to avoid such a situation. I checked their features (and lack of) until I finally found one that fit the bill. For a long time that engine worked very well, at least while it was being supported. However, back in December, after having just signed with Image Space Incorporated to bring some funding to RogSys development, it became readily obvious that the author of the engine had bailed on it (despite many emails and promises to the contrary). I broke out my notes about the other engines I'd looked at and created a short-list of possible replacements. The list was VERY short, actually--zero in fact. So, I started looking at fresh alternatives. It HAD been a couple years since I was on the market. During the search I happened to recall a sim titled Combat Helo; and having liked what they had accomplished to date, AND since RogSys is VERY sim-like, I decided to give Leadwerks a look. Version 3.1 was getting ready to come out, I'd discovered, and the deferred renderer caught my interest. I knew there was somewhat of an overhead with a deferred system, but the lighting possibilities quickly make up for that. Also, after spending a few evenings with the online API reference I realized Le's command set was similar to what I'd been using. I knew there could be some issues with a fresh engine version (bugs, etc), but based on the forum communication from Josh I felt the support was there and any potential problems would be fixed up. Understandably, ISI began to get a tad nervous about the situation. I told them about my decision to go with Leadwerks. They were fine with it as long as I could get some momentum going ASAP. I'd already started re-coding my old engine wrapper based around the Le API, but obviously it was impossible to test until I had something I could compile against. So, Josh managed to hook me up with the C++ project template for the Indie version. The first item to tackle was getting my foreground and background worlds rendering over top of each other. Because of the scale of RogSys (an entire galactic arm) I render the celestial objects at one scale in the BG world, and all the local elements at 1 to 1 in the foreground world. Klepto2 and Shadmar were gracious enough to help with this early implementation. While it works well enough for now, with a deferred renderer two worlds probably isn't the most efficient method. If Josh can add support at some point to allow me to force certain objects to render behind others (or some other method of manual sorting) I can move everything into one world. But, for now, I at least had a system that allowed me to move forward. The next step was to get all of my data files to play nice with Leadwerks. All of the ships in RogSys are built from different systems that can be mixed and matched, so nothing is predetermined. The same ship hull could have a slew of different components added to it (internally AND externally) and thus no two ships are rarely alike. Also, a BIG feature is the ability for the user to mod it--adding new ships, ship systems, missions, etc. It's all externalized.These are features that aren't terribly important in the initial release, but in the first update I'll be adding a sandbox-like exploration mode and that's when these will play a major role. But, they're very low-level and so have to work from day one. So, once I read in the data from my LUA tables I had to get Leadwerks to build materials on the fly from various shaders and maps, all of which are defined in the setup files. This took about a week. When loading and using resources on the fly probably the biggest note I could make is to remember to release the temporary elements (textures, shapes, etc). By this time I had a pretty good grasp of the basic engine, but as I moved into the low-level stuff I had lots of questions. I can tell by the editor and LUA scripting that Josh has worked hard to allow novices the ability to bring game ideas to life and to keep them "safe" from the lower API. But for my needs, I had to get down in there. A big thanks to Josh and others for always being Johnny-on-the-spot with answers. My item of advice here is to always do a forum search first. While I had lots of questions, I can tell you I answered MOST of them on my own with a quick search. It was the ones when I got "no results found" where I had to ask for help. On the C++ side, one of the things that tripped me up a lot at first was the format: someShape = Shape::Create(); I can't tell you how many times I would type: someShape->Create(); which compiles, but does not give the results you'd expect. Silly, I know Once I had objects loading and being surfaced the way I needed things became a bit more straight-forward. I can now walk around inside my station interior, load and position docked ships to the proper stalls. I have ray casting working so the player can look at and use items. The online tutorials were a big help getting familiar with some of these basic things--thanks to Aggror, Rick and Josh for those. USE them--they help. And, I think I've been typing for a while now, and I have to get back to work, so I'll end this here. I was really going for a general overview of what brought me here, and I think I have that covered From here out I'll try to focus a bit more on specific items and how I handle them in Le. I'll probably talk about various hooks first--I'm already finding them very useful. One last note, and it's probably most important, thanks to Shadmar for offering to help me out with some shader work. Not having to get my head around GLSL right now is a HUGE time saver; and I appreciate it! And again, thanks to Josh and anyone else who's helped me out over the past couple of months. Cheers....

Yeah, that's a fair comment. I'll do that from here out for the "unsupported" issues as they arise...

Again, that's understood, which is why I'm not sure it can be classified as a bug. If not then I think it at least warrants a mention somewhere for reference. In hindsight, the "programming" section probably should have been the first stop for this. My bad there

True, but it's the cleanest way to get states for all the keys each frame. I fully expect, seeing as RogSys is a sim, that people will use as many keys as possible for different systems control, and I have a LUA table that allows user-defined keys and buttons. I couldn't imagine having to do an independent "if" for all those key states separately I mean, functionally it's the same thing as putting one "if" inside a loop, but code-wise it's just seems a bit... ugly... Edit: I think in many cases (and Josh, correct me if I'm wrong here), there just hasn't been time to document everything yet. If so I would believe this to be one of those cases, as a loop-able downstate for keys and buttons is pretty common. That said, if I can see it and it will save me coding time you can bet I'll try it. If it's not supported and doesn't work THEN I'll code around it

I'm not sure if this constitutes a bug, or is expected behavior (already discussed with Josh, just adding a post for a reminder) I do not do any KeyDown or KeyHit checks in my app::loop. Rather, I have a controller class that handles everything (joysticks, keyboard, mouse, etc) that I call once per frame. For the keyboard functionality I use Window::keydownstate[] which works well. However, without any calls to KeyDown or KeyHit this causes Windows to think that the program has become unresponsive, even though you can see the program is still running (mouse control still works, engine still updates, etc). To correct this "bug" there has to be at least ONE call somewhere, per frame, to either KeyDown or KeyHit. Here's test c++ code so you can see the behavior. Note: if you don't un-comment the first line in the App::Loop you WILL have to shut down the prog with Task Manager... #include "App.h" using namespace Leadwerks; class keyGRABBER { public: bool Shutdown(Window*); }; bool keyGRABBER::Shutdown(Window* window) { if (window->keydownstate[27]) return true; return false; } keyGRABBER getKeys; App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {} App::~App() { delete world; delete window; } bool App::Start() { window = Window::Create("test", 0,0,1024,768,Window::Titlebar + Window::Center); context = Context::Create(window); world = World::Create(); camera = Camera::Create(); camera->SetRange(0.05, 5000); return true; } bool App::Loop() { //if (window->KeyDown(Key::Escape)){}; //uncomment this to fix the bug if (getKeys.Shutdown(window)) { //End program return false; } else { //Continue Time::Update(); world->Update(); world->Render(); context->Sync(true); return true; } } Excuse the code--I just threw the example together quickly so I can get back to work Anyway, keydownstate may not poll for windows activity on its own, in which case this isn't a bug per say. But I wanted to at least make a post about it so no one else trips over this. I spent 4 hours tracking this down

As previously announced -- Rogue System. Working on engine integration right now with current game code. I plan a release-able alpha version in very early 2015. I would expect Josh to have the major issues sorted by then, as well as an optimization pass or two done...

I understand this is how it works on the 3.1 demo. I'm sure there may be other performance issues at the moment; but, this CAN drop frame rate briefly (micro-stutter) as verified by both MS and AMD (for various reasons). I tested my prog, as well as the tutorial above, on my other rig (Win 7 with nVidia) and all is well--FPS is stable when moving the mouse. I've confirmed this by locking the camera and moving the mouse--when the mouse is still the FPS are stable, when it moves they drop. I've done this with physics and camera lighting enabled and disabled--same result. Now, I've had 3 people tell me they have Win 8.1 and no problems, but I'm not sure (except in one case) what vid cards they have. My guess would be nVidia. Sometime this week I'll verify by moving my nVidia to this 8.1 rig and see what happens... Otherwise, there is something wrong with this rig, which could certainly be possible. Actually I'd prefer that because then it's an isolated case and doesn't reflect a deeper issue... The other possibility is the mouse is reflecting another issue in which case I'd still like to know what that issue is that seems to be machine-specific (based on my local test here)... Oh well--too busy to really worry about it right now

Some more info on this: this has NOTHING to do with the camera itself rotating. The FPS stuttering is a direct result of the mouse pointer being re-centered over and over (as is common practice for any sort of "mouse look". This is either an issue with my Radeon r9 290, or Windows 8.1 (both Microsoft and AMD have confirmed cases of stuttering when turning the camera, which again would use this method). So, the question now is what to do about it. I've tried re-centering the mouse on one frame and taking a difference reading on the next, but that didn't help. Obviously you have to recenter the mouse or eventually you'll hit a stop, so I'm not sure how else this could be managed in game code.

Precisely why I asked

Understood, but if you look at the tutorial a delete is never done so obviously I wanted to verify... edit: the tutorial in question, by the way: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/object/objectsetuserdata-r22

Thanks, Josh--just checking if I had to do clean up or not. Thanks for the extra info, Rick. Yeah, I already have collision callbacks working and was using the documented method to pass data. Being able to link them as you describe certainly streamlines things a bit

Quick question: If I do something like: EntityData* entitydata = new EntityData; model->SetUserData(entitydata); Since I use a "new" do I have to "delete" the data before destroying the entity, or does the entity's destructor handle that for me? Thanks

Well, I'm not sure what precisely is causing it. I've tried both the latest AMD release and beta drivers (WARNING: for me, I got a noticeable pause every second in debug mode with the beta driver), and did some other suggestions I found to no avail. Actually, it was better when I had my video driver completely uninstalled, but that makes my triple-monitor setup useless... If anyone else runs across this, or something similar, please leave a comment. Thanks...

Let me guess, you're NOT running Windows 8.1, right? http://support.microsoft.com/kb/2908279 Supposedly Josh might be able to correct this on his end, but I don't know the details...

The second video is showing a GPU-based particle system. EVERYTHING is handled on the GPU--Newton would have nothing to do with it. The thing about GPU systems is that it's easy to feed information to the particle and the emitter, but there's no real way to get any information back (that I know of), so this sort of system is solely for visual FX. If you needed to know if a bullet strikes a character, or if a missile hits a target, then you'd still need to use traditional methods....