Jump to content

Flexman

Members
  • Posts

    916
  • Joined

  • Last visited

Posts posted by Flexman

  1. softparticles.frag

     

    You might have a material called "softdust.mat" or "smoke.mat" that uses it. I'm not clear what comes with the standard LE package anymore. But thats probably what you're after, particles that blend the edges softly with geometry.

  2. An Identity Matrix is...

    mat.ix=1 ; mat.iy=0 ; mat.iz=0 ; mat.iw=0
    mat.jx=0 ; mat.jy=1 ; mat.jz=0 ; mat.jw=0
    mat.kx=0 ; mat.ky=0 ; mat.kz=1 ; mat.kw=0
    mat.tx=0 ; mat.ty=0 ; mat.tz=0 ; mat.tw=1
    

    Scale for XYZ is ix, jy, kz

    Position XYZ is tx , ty , tz

     

    The tricky part is rotation. I tried to write a quick function that I thought would demonstrate it but I kept getting an exception error LOL. I'll come back to it if I figure out why. I wonder if Leadwerks does something funny for rotations.

  3. I've been coding since LE v2.21 on 3 monitors for a long time now courtesy of Maxtrox Tripplehead2Go. So long as Eyefinity works in a similar transparent way (a single virtual display device) it shouldn't matter. Just set your screen resolution and go.

     

    If it requires specific support then it's probably not worth the trouble unless you're doing OEM work or a simulation project which requires it.

     

    As far as I've been able to determine, ATI's Eyefinity SDK is mostly about pulling driver specific information about bezel management and aspect ratios.

     

    Aspect can be easily compute in leadwerks friendly format with:

      aspectratio = float(GraphicsWidth() / GraphicsHeight()) ;
    

     

    The bulk of the ATI docs on Eyefinity programming seems more "best practice". So Leadwerks should work out of the box with Eyefinity. Any special commmands for supporting it should come from using ATI's SDK which is a matter for the programmer.

     

    http://sites.amd.com/us/Documents/ADL_ATI_Eyefinity_SDK_Whitepaper_v1.0_FINAL.pdf

     

    Hope that answers your questions.

  4. It's the shadows that are expensive with point lights. Don't use shadowing with your point lights unless you need them, or simply turn them on when they are in a useful range. Combined with point of interest light sources (ones used to generate shadows or effects) you can mask the absence of shadows from every light source well. Game programming is all tricks.

     

    We use dozens of the things every frame and they perform great (and these are moving).

  5. It's a single plane that follows the camera around. If you need to have separate bodies of water what we did was make a mesh and apply a water surface material to it. But this prevents the use of buoyancy physics unless you're OK in your level design to change it when you get close to one of these water body entities. Fiddly.

  6. Generally for single applications using SLI you need to run in fullscreen (some driver hardware combos will work for windowed applications).

    But you're trying to do something different as understand, use a single GPU per application instance. As far as I'm aware OpenGL lacks control over things like this. The NVAPI might help out.

     

    I saw an extension that is supposed to set GPU Affinity in OpenGL (DirectX can do this)....

    http://www.opengl.org/registry/specs/NV/gpu_affinity.txt

     

     

    You might also want to have a skim through nVidia SLI Best Practices document...

    http://developer.download.nvidia.com/whitepapers/2011/SLI_Best_Practices_2011_Feb.pdf

  7. Understandable. The techniques however are solid and used in other engines (OpenScenegraph, Infinity and Outerra) and games (FSX, X-Plane) all these are referenced in the text. Elliptical clip-maps and camera relative rendering (they call it Rendering Relative to Eye) is used in all manner of simulations where any large scale world is required.

     

    What's new are the techniques to do it on the GPU and code you can play with instead of read about in research papers. But if you're looking to create some really advanced terrain that can go from ground zero to outer space this is a good place to get a broad view of how it's done in Google Earth and NASA World Wind.

     

    I know some of the references used in the book, we were in negotiation with one source, small community. I dare say it could all be optimised and improved for even better game performance. Google Earth runs fine on the iPhone so it must be pretty efficient.

     

    On the whole, it would be nice to to choose what kind of terrain rendering to have, like Ogre3D, might be an option. From SimpleTerrain to VoxelTerrain to LargeTerrain supporting elliptical worlds, huge co-ordinate systems and streaming. We get all the benefits of the Leadwerks pipeline and code the way we want. Just something to consider since everyone seems to have their own ideas on what they want to do. Not everyone needs terrain so a separate plugin/DLL, this would reduce the disk footprint too.

  8. I'd like to be able to plug in a terrain system that deals with scale and accuracy issues.

    Like the one dicussed in this book... http://www.virtualglobebook.com/

     

    Slideshow presentation...

    http://www.virtualglobebook.com/Under_the_Hood_of_Virtual_Globes.pdf

     

    Example chapter...

    http://www.virtualglobebook.com/3DEngineDesignForVirtualGlobesChapter1.pdf

     

    I've been playing with some of the example code and it's very efficient. Itching to try some flight physics with this.

  9. Presentation is everything. I reckon you could make a pretty compelling game of PONG if you disguise it well enough. Look at Angry Birds, tell me what ancient game that is dressed up? Turn Pong into a small planet or moon with low gravity, the ball is a nuke or grenade that 'heats up' and cools making it possible to kill your opponent in amusing ways. Take a simple idea and throw progressively more stupid ones till you find one that sticks and motivates you.

     

    With Leadwerks you can put together a simple tower defence or RTS, or even a 2.5D platformer as all mentioned above. The HARD part is finishing, no matter what game you decide to make, you get to about the 80% completion mark and then you find the other 80% of polishing work left to do.

     

    Just my 0.02 euros.

  10. Well if you have a mesh for the head, go one step further and add a bone for the jaw then experiment moving that bone to get your head to 'talk'. I've seen a few commercial products for doing this.

     

    I remember something for DarkBasic called DarkVoices that was a system for creating lip-sync files, there's a video showing how the model was created, this might give you a head-start on how to approach this.

     

    http://www.thegamecreators.com/?m=view_product&id=2107

  11. Question, does it need to run on 3 different display devices?

     

    I use a 3840 x 1024 split over three monitors using the Matrox Digital TrippleHead2Go which makes the video card think it's plugged into one large physical display device. The Matrox device splits it into 3 DVI signals. Combined with display software that can warp your screen output to match the geometry of any curved screen...

     

    Well here's a video of a guy who built his own collimated display using reflective mylar shaped by a vacuum...

     

    He's using the Matrox Tripplehead on 3 projectors.

  12. One of the elements in the DirectInput DLL I made is a feature that detects the OEM flags of a device using GetDeviceInfo(DIDEVICEINSTANCE)

    The reason for this is that I need to support some some LED features on the device. A small OEM library is provided to support these.

     

    The code snippet below is just an example of how to pull out some manufacturer info for a specific device instance (joystick).

     

    
    CONST DWORD VID_LOGITECH = 0x046d;
    CONST DWORD VID_MICROSOFT = 0x045e;
    
    ...
    
    DIDEVICEINSTANCE  device;
    
    /* MUST set these for any DI structure before use or bad things happen */
    ZeroMemory(&device, sizeof(device));
    device.dwSize = sizeof(device);
    
    if (FAILED(hr = joystick->GetDeviceInfo(&device))) {
    return hr;
    }
    ...
    ...
    DWORD vidPid_ = device.guidProduct.Data1;
    this->vid = LOWORD(vidPid_);
    this->pid = HIWORD(vidPid_);
    
    if (VID_LOGITECH == this->vid) {
      /*  do some OEM stuff here */
      if (PID_G940_THROTTLE == this->pid ) {
         /* the product ID matches special hardware so do something here */
      }
    }
    
    

     

     

    I don't have a problem per say, I'm more in deed of reassurance and guidance. The extras library for LED control is provided 'as is' by Logitech and compiled using Visual Studio 2008 however since I'm working with a more recent (VS2010) editor I get the LNK4099 error.

     

    Now I can get it to link by changing the project options [ LINKER > Debugging > Generate Debug Info = "No" ]. I think it's complaining that the object data in the supplied library isn't in a format VS2010 likes. It seems to work OK and I can set all the special lamp switches, LED colour and all the joystick functions no problem. Even multiple devices (I have 3 HOTAS systems plugged in at the same time, that about 1,000 UKP worth of flight simulation controls). And I'm not seeing any problems functionally.

     

    From the online searches I did on this error most people say DONT without explaining why. Can it seriously be that big of a problem in a release build? Logitech don't supply the source to rebuild the library, it's provided 'as is'.

  13. Yes, that's how I did it originally, pivot points all over. In practice it doesn't work out too well. When players have tripple-head devices (or even 5 screens with Eyefinity setups) things can still get clipped. What looked good on one setup was clipped on another, it became a pain adjusting things to work on different display sizes. You're dealing with objects that have vital buttons arrayed around the outer edges where any form of clipping renders the instrument near useless. So yes good in theory, practice not so much :/

     

    For tutorials it's handy to be able to script "show me this instrument" or "this switch panel" and not have to setup camera positions, just add the object name.

  14. That might work in a blank scene like an editor.

     

    The problem is that the camera is in a busy cockpit. The goal is to have a hotkey move the camera to quickly look down at different parts of the cockpit up close.

     

    screenshot2356.jpg

     

    My chosen method is to dolly the camera backwards until two (or more) objects, in this case two screens, fill the viewport. The solution should be is a simple triangle problem.

     

    targetAABB = combined AABB volume of required entities.

     

      bboxW = (targetAABB.w * 0.5) / tan(game.scene.camfov * 0.5) ;
      bboxH = (targetAABB.h * 0.5) / tan(game.scene.camfov * 0.5) ;
      dollyZ = max(bboxW, bboxH) ;
    

     

    The camera is positioned at the centre of the TargetAABB volume and dollied backwards by "dollyZ"

     

      camerapos = Vec3(targetAABB.cx, targetAABB.cy, targetAABB.cz - dollyZ);
    

     

    For the most part that works if the screen resolution/aspect ratio is square. HOWEVER...

    I need a third step, adapt it for the current aspect ratio. This is where it falls down. If the screen is 3840x1024 pixels with a camera FoV of 120 degrees (a letterbox shaped screen) the top and bottom of the objects are off screen. Like this...

     

    screenshot2359.jpg

     

     

    I'm scratching my head on how to cram the aspect ratio into this. Changing the FoV to solve this is not allowed.

     

    *update*

     

    OK. Seems if I fudge the following... aspect is screenwidth / screenheight

     

      bboxW = (targetAABB.w * aspect) / tan(game.scene.camfov * 0.5) ;
      bboxH = (targetAABB.h * aspect) / tan(game.scene.camfov * 0.5) ;
      dollyZ = max(bboxW, bboxH) + 0.05 ;
    

     

    It seems to work. 0.05 is added as a little extra. The result for our near worst case looks like this...

     

    screenshot2361.jpg

     

    Now I have to hide the joystick as it's getting in the way of the virtual cockpit raycasts.

×
×
  • Create New...