Jump to content

Flexman

Members
  • Posts

    916
  • Joined

  • Last visited

Posts posted by Flexman

  1. DudeAwesome's suggestion will work fine. In LE2 you had a PickFilter callback which was really handy for this kind of thing.

     

    We had a slightly different problem, scan large areas containing 1 to many widely spaced entities (for simulating radar sweeps). We would first compute an axis aligned bounding box for the scan volume, then generate a collection of potential entities using worldforeachentityinaabbdo then reject based on angle of entity to the source. The final step was performing line of sight tests on the remaining collection. Since radar sweeps occur every few seconds it's not a problem spreading the task over time.

     

    A different problem but the above might help someone else trying to do the same.

    • Upvote 1
  2. Interesting idea. A bit like how in Kerbal Space Program has different render horizons.

     

    I remember Klepto made some cubemap reflection code for Leadwerks 2.x that rendered each side of the cube. It was quite efficient as it rendered on face per frame. So it took 6 frames to complete a full update of the cubemap.

     

    Take at look at his implementation, may or may not work in LE3 (will need some conversion):

    http://www.leadwerks.com/werkspace/blog/16/entry-654-cubemaps-realtime-here-we-go/

  3. I'm guessing Josh knows the answer to this and probably pretty busy atm, but I'll throw this out here in case someone can tell me.

     

    Modifying particles.vert to create an emitter commonly used for clouds and smoke trails.

     

     

    Trying to determine a lighting normal based on the vertex position so a particle quad on the opposite side to a light source (the sun) is darker. I'm computing the lighting normal in particles.vert using the following....

     

    float Lnorm = dot(normalize(-LightSource.xyz), normalize(- vertpos.xyz)); // compute lighting normal
    ...
    ...
    gl_FrontColor.xyz = mix( outcolor.xyz , vec3(0.0) , Lnorm); // finally set the vertex color
    

     

    I'm missing something in the way the verts in an emitter object are constructed. Or my math is just plain wrong. Or both. But I think I'm having trouble because the verts are computed in camera space, not model space (as particles are just points).

  4. Guys. I have no problem to change my mind when convinced with good arguments. So I do smile.png

     

    I guess it's not so much about that as how to protect them in Leadwerks. There's value to be had in open source games from the asset store. I learned a lot about writing better LUA from having someone look at my code and giving me feed back (er fixing it - cheers Mac). So there is a benefit to sharing too.

     

    Asset vendors such as Pure3D or Dexsoft require some kind of asset protection in their license terms. Password protected ZIP files satisfy this requirement for LE projects.

     

    It would be nice to have an all in one process to build and package everything.

  5. If the user wants to hack the game, why not let him?

     

    It depends what they do with it at that point. I work with a "White Hat" hacker and have an appreciation that no matter what you do there's someone smarter with a better tool. I didn't know you can just plug a device into firewire or a USB port and break into any locked system as you have direct access to system memory via high speed interfaces. What an awesome hardware design!

     

    My first commercial game product was the result of reverse engineering which predates but would now fall foul of the DMCA. But there's so much more potential for monetary losses/gains now micro-transactions are here to stay.

     

    Game assets need to be protected to some degree, not least because there's always some nut-job willing to upload and sell them on an asset store to unsuspecting game developers who then become victims.

  6. I remember that change. Really screwed up our game as we do ray casts at altitude for targeting, weight on wheels, radar altitude. Every time you passed over an entity the game would pause as the engine built some internal structure. All is well now though.

     

    Raycasting for ballistics, physics for feedback (sometimes, depends on the context).

  7. I can see a case for it. I grew up with low level access and a lot of creativity came out of it.

     

    (Secretly - I still don't really know what it is. I read this, look at that....still a bit clueless)

  8. It's possibly not working because my psudo code above didn't take into account that GetVelocity returns a vector. You need to multiply the returned velocity.

    Vec3( 0.9 * Time::GetSpeed() , 0.9 * Time::GetSpeed() , 0.9 * Time::GetSpeed() )

     

    You can't multiply a Vec3 by a single value and expect a Vec3 in return. If your code is LUA you're passing a weird value and that's why it's coming to a halt.

  9. If you can do what Josh says, that's the easy option. If that fails you don't need to apply opposite forces. Just multiply it's own force by a smaller value than 1.0

     

    psudo code...

     

     cameraBody->SetVelocity( cameraBody->GetVelocity() * (0.9 * appspeed()) );

     

    Do that when not moving the camera.

     

    Might want to add commands to set the dampening values to the suggestion box.

     

    I suspect AddForce is not what I think it is. It reads like it's additive rather than absolute. BUT if you have write access to the velocity properties (can't test atm) it should be easy to multiply those values by 0.9 every frame to reduce them close to zero over time.

     

    You don't notice missing commands until you try and do something that needs them.

  10. Isn't linear and angular damping different from friction? Friction is applied when a body interacts with another body. Dampening occurs over time.

     

    Just a thought. Not sure what you're doing with your camera.

     

    edit: Oh I just looked at the Leadwerks 3 commands, are there any commands for setting linear and angular dampening like you can in LE2 using SetBodyDamping()? It's not obvious to me.

     

    edit2: I guess you could just multiply the velocity of the body by a value less than 1.0 in an UpdatePhysics() callback. That would do it.

    • Upvote 1
  11. Why do you want to bypass the provided terrain system?

     

    Because you can't implement a terrain tile treadmill system with the provided TTerrain. With two cameras and a terrain tile-set you can have infinite terrain and no buffer problems.

     

    If vegetation was modified so it could be parented to a particular tile then there would be no limits and best of both worlds.

  12. At first glance, it appears it only relies on terrain for aligning instances to the terrain, something the editor does at when painting vegetation. It might be possible to separate it out from the terrain. Using a mesh with unique geometry would consume an enormous amount of memory for the size of terrains Leadwerks does.

     

    The problem here is the use of the singular. Otherwise your assertion would be correct.

     

    You wouldn't use a single mesh for terrain unless the engine can stream in the data. The memory footprint for terrain meshes isn't an issue at all. It can be pretty small (and should be) or machine crippling vertex limit bus-tingly huge. (One tool will go over the 64k vertex limit on export but that format is meant for streaming in small sections).

     

    Tools like World Machine, GROME and others (which we won't mention to comply with forum rules) take large world databases and split them into tiles, with the option to have regular or non-regular meshes. Other Leadwerks users are using this technique but it would be nice to figure out if we could do the same AND keep the nice vegetation system.

     

    It's pretty easy to create much larger scrolling terrains that represent thousands of km. using tiles. It's a doddle to script in another engine using just two cameras because you have the simple benefit of more than one Terrain object acting as a parent for the content. I'm not a big fan of that particular engine as it's hard to manage large projects and worst of all, the lighting is not great.

     

    We can't have more than one Terrain object in leadwerks but we have a tile set for terrain and can dolly it around. But if it were possible to load into memory (and remove) vegetation for a particular AABB then the problem would be solved. I know the vegetation is stored as a quadtree and the enhanced DLL exposes some fantastic functionality to enable adding and removing vegetation.

     

    Anyway, just some thoughts you might want to carry over to Leadwerks 3.x

  13. A Leadwerks 2 question which I may have asked before.

     

    The vegetation system seem tied to the terrain by virtual of all the extended vegetation commands needing to pass the (singular) TTerrain object.

     

    But is it possible to have all the vegetation layers but use your own meshes for the terrain? What is the relationship between vegetation the TTerrain object? Is it just for used for height positioning/slope alignment and grid spacing? In which case they might be separated.

  14. Generally, when you export you want to collapse everything into a single mesh. If each beam in that shelf were a separate object, it would take dozens of rendering passes, but it will only take one if it's collapsed to a single object.

     

    What if an object with different parts only used a single material?

  15. I just got back from a dev conference where TDD was one of the topics covered (my day job for the past year happens to be a technical tester/engineer embedded in the platform team). I think you're wanting some practical code?

     

    We don't perform much in the way of TDD, it's more about aiding design and rapid iteration. I can tell you there are ongoing arguments about what TDD is and what value it has. For small projects it has its place.

     

    Say you were creating a Darts game.

     

    You'll want to code and test scoring. What happens in darts? A player starting with 501 points throws a dart at a board. If he hits one of the scoring sectors the value of that sector is subtracted from the player score. The player wins when the score is reduced to exactly zero.

     

    Right away this gives us some code to add and we can test as we iterate through the game development.

     

    If the player hits the board, check which sector, calculate sector_score_value, subtract score from players current_score if score > 0 + sector_score_value.

     

    So you're going to create tests for state (dart in flight? hit board? game over?), interactions (dart hit sector x) and returned values (score from sector x). If you add tests for those, including several covering the different score subtraction conditions, if they pass then the logic should be sound.

     

    Tests you wouldn't add; UI behavior (clicking a button), calling a method (methods don't return values, so what are you testing? That you can call a method?).

     

    Generally we'd lump those kinds of tests in with Unit Tests for VisualStudio (using [TestMethod] and [TestClass] declarations for test builds).

     

    Don't over-think, tests add code and can slow you down. So stick to tests around state transitions, object interactions and functions. Also don't blindly follow other peoples rules and advice :) It's not about the number of tests you do, it's the quality.

     

    Hope that's of at least some help.

  16. That looks great at eye level. Good vegetation varieties and texture blending. I've no idea how to procedurally generate roads or texture masks in LE2 although the texture masks.

     

    What can be done about the repeating pattern at the 100ft viewpoint or is that not going to be an in-game issue? I think we had this issue and fixed up the mip-map levels to make it go away.

×
×
  • Create New...