How do you create an AIPlayer without an AIPlayer connection? Is that how TBM does clonebots now? If so that needs to be improved upon if you want to populate cities or large structures, space stations, etc.
So you're trying to make a AI Crowd system?
elfprince13 wrote:
This image may not look like much to you, but it's the first indication that a complete overhaul of the graphics and physics subsystems of the Freebuild engine are under way.


After devoting quite a few hours to rewriting the rendering code on my own, I decided to completely tear out the existing rendering pipeline and replace it with a high-performance open source solution (that will also more easily integrate with the Bullet physics engine we will use to power the new vehicle/train systems). OpenSceneGraph is an extensible SceneGraph library designed for easy extensibility and high performance rendering. At this point I'm drawing only an empty scene, but the entire GameRenderWorld() method has been replaced with OSG code, and once I write some plugins to support LDraw and Torque art assets, we'll be up and running pretty quickly. I'm hoping that this won't take more than a couple of weeks, but like always, life is busy and we'll see how things progress, and I'll try and post frequent updates on my progress.


wait... does that mean, that freebuild will need a good graphics card to run it well?
Welcome back, Xyno. It means you need a decent card to run it at decent speeds, and a good graphics card to run it at excellent speeds.
I'm not sure it's gonna be quite that high-end. Today's good and great cards have a lot of fancy features that I doubt FreeBuild will be making much use of. Integrated Intel is probably all you're gonna need.
Just on a side note, I was brainstorming ideas about track-following train mechanics in Freebuild with my friend Arcades this evening.
The overhauled FreeBuild (so far) still runs just fine on my NVidia integrated card (a 9400M) and my higher-power card (a 9600M GT), though I haven't tested it on anything Intel.

KermMartian wrote:
Just on a side note, I was brainstorming ideas about track-following train mechanics in Freebuild with my friend Arcades this evening.

w00t. What did you come up with?


DShiznit: Go look at the CAI source, or the followbots in old school TBM. They never used AI Clients.
Yet they lagged like hell when a lot of them were used. I'm fairly certain CemetechAI used AIConnections in at least one incarnation, as I remember each bot having a spot on the player list, but I suppose that could have been faked.
DShiznit wrote:
Yet they lagged like hell when a lot of them were used.

If I had known more about Torque when I wrote them, they probably wouldn't. Also, if I'd used a client I wouldn't have had to write all the nasty fake-physics code for flying and swimming, because I could have just used triggers.

DShiznit wrote:
I'm fairly certain CemetechAI used AIConnections in at least one incarnation, as I remember each bot having a spot on the player list, but I suppose that could have been faked.

No, they don't, and haven't. Not in any form that I ever released, I distinctly remember faking certain client specific methods on the bot player object itself. The player list stuff was faked.

[edit]
I'm going to bed for the night, but after hours of playing around with Hammer, QuArK, Constructor, Blender, and GTKRadiant I'm calling the dif-disposal quest a fruitless one and have begun extending the existing OSG bsp plugins to handle dif as well as the iD/Valve formats.

I would have been happy to have my maps, the Kermcave and Shiznit's work in some other format and ditch ALL the other interiors, but it looks I'm going to have to buckle down and write the plugin after all. SCREW GarageGames and Constructor for having broken lwo texturing, and saving to Valve's .map format instead of the more widely supported Quake .map, or something actually useful. SCREW GTKRadiant for only supporting Quake-style .maps. SCREW Valve, Hammer, and the Source SDK for being a priority, useless p.o.s.. SCREW QuArK for only knowing how to handle builtin Steam apps, and not mods in the SDK, and for not having something resembling a decent retexturing tool.

At least I finally got a license for HL2 out of the mouse.

[edit - 2]
On the productive side of things, I've rewritten the Q3BSPReader and VBSPReader classes to extend a new base class called "BSPReader" (instead of being independent of each other) and started a new class called DIFReader. This has allowed me to streamline the ReaderWriterBSP::readNode method from this:


Code:
ReaderWriter::ReadResult ReaderWriterBSP::readNode(
                                  const std::string& file,
                                  const ReaderWriter::Options* options) const
{
    VBSPReader *               vbspReader;
    Q3BSPReader *              q3bspReader;
    ref_ptr<Node>              result;
    osgDB::ifstream            stream;
    int                        magicNumber;
    int                        version;

    // See if we handle this kind of file
    if (!acceptsExtension(osgDB::getFileExtension(file)))
        return ReadResult::FILE_NOT_HANDLED;

    // See if we can find the requested file
    std::string fileName = osgDB::findDataFile(file, options);
    if (fileName.empty())
        return ReadResult::FILE_NOT_FOUND;

    // Open the file and read the magic number and version
    stream.open(fileName.c_str(), std::ios::binary);
    stream.read((char *) &magicNumber, sizeof(int));
    stream.read((char *) &version, sizeof(int));
    stream.close();

    // See which kind of BSP file this is
    if ((magicNumber == VBSP_MAGIC_NUMBER) &&
        (version >= 19) && (version <= 20))
    {
        // Read the Valve file
        vbspReader = new VBSPReader();
        if (vbspReader->readFile(fileName))
        {
            // Get the results of our read
            result = vbspReader->getRootNode();

            // Clean up the reader
            delete vbspReader;

            // Return the results
            return ReadResult(result.get());
        }
        else
        {
            // Clean up the reader
            delete vbspReader;

            // Return the error
            return ReadResult::ERROR_IN_READING_FILE;
        }
    }
    else if ((magicNumber == IBSP_MAGIC_NUMBER) && (version == 0x2E))
    {
        // Read the Quake 3 file
        q3bspReader = new Q3BSPReader();
        if (q3bspReader->readFile(file, options))
        {
            // Get the results of our read
            result = q3bspReader->getRootNode();

            // Clean up the reader
            delete q3bspReader;

            // Return the results
            return ReadResult(result.get());
        }
        else
        {
            // Clean up the reader
            delete q3bspReader;

            // Return the error
            return ReadResult::ERROR_IN_READING_FILE;
        }
    }

    return ReadResult::FILE_NOT_HANDLED;
}


to this:

Code:
ReaderWriter::ReadResult ReaderWriterBSP::readNode(
                                  const std::string& file,
                                  const ReaderWriter::Options* options) const
{
    BSPReader *               bspReader;
    ref_ptr<Node>              result;
    osgDB::ifstream            stream;
    int                        magicNumber;
    int                        version;
    std::string ext = osgDB::getFileExtension(file);

    // See if we handle this kind of file
    if (!acceptsExtension(ext))
        return ReadResult::FILE_NOT_HANDLED;

    // See if we can find the requested file
    std::string fileName = osgDB::findDataFile(file, options);
    if (fileName.empty())
        return ReadResult::FILE_NOT_FOUND;
   
    bspReader = NULL;
    if(osgDB::equalCaseInsensitive(ext, "dif")){
        //We have a Dynamix Interior File - Probably Torque Game Engine or similar
        bspReader = new DIFReader();
       
    } else if (osgDB::equalCaseInsensitive(ext, "bsp") || ext.empty()){
       
       
        // Open the file and read the magic number and version
        stream.open(fileName.c_str(), std::ios::binary);
        stream.read((char *) &magicNumber, sizeof(int));
        stream.read((char *) &version, sizeof(int));
        stream.close();
       
        // See which kind of BSP file this is
        if ((magicNumber == VBSP_MAGIC_NUMBER) &&
            (version >= 19) && (version <= 20))
        {
            // Read the Valve file
            bspReader = new VBSPReader();
        }
        else if ((magicNumber == IBSP_MAGIC_NUMBER) && (version == 0x2E))
        {
            // Read the Quake 3 file
            bspReader = new Q3BSPReader();
        }
       
    }
    if(bspReader){
       
        ReadResult retval = (bspReader->readFile(fileName, options)) ? ReadResult(bspReader->getRootNode().get()) : ReadResult::ERROR_IN_READING_FILE;
        delete bspReader;
        return retval;
    } else{
        return ReadResult::FILE_NOT_HANDLED;
       
    }

}
Today my code can began reading the LOD information out of a dts, and depending on how the prob/stat homework goes and how many students come in during my office hours for CS111, I'd like to be able to pull out the texture coordinates and the mesh information by the end of the night (or at least one of the two). I figure BSP collision data can be put on hold until I get around to physics code and collision detection. Tomorrow is my busiest day, so we'll see how it goes.
elfprince13 wrote:
DShiznit wrote:
Yet they lagged like hell when a lot of them were used.

If I had known more about Torque when I wrote them, they probably wouldn't. Also, if I'd used a client I wouldn't have had to write all the nasty fake-physics code for flying and swimming, because I could have just used triggers.

DShiznit wrote:
I'm fairly certain CemetechAI used AIConnections in at least one incarnation, as I remember each bot having a spot on the player list, but I suppose that could have been faked.

No, they don't, and haven't. Not in any form that I ever released, I distinctly remember faking certain client specific methods on the bot player object itself. The player list stuff was faked.

[edit]
I'm going to bed for the night, but after hours of playing around with Hammer, QuArK, Constructor, Blender, and GTKRadiant I'm calling the dif-disposal quest a fruitless one and have begun extending the existing OSG bsp plugins to handle dif as well as the iD/Valve formats.

I would have been happy to have my maps, the Kermcave and Shiznit's work in some other format and ditch ALL the other interiors, but it looks I'm going to have to buckle down and write the plugin after all. SCREW GarageGames and Constructor for having broken lwo texturing, and saving to Valve's .map format instead of the more widely supported Quake .map, or something actually useful. SCREW GTKRadiant for only supporting Quake-style .maps. SCREW Valve, Hammer, and the Source SDK for being a priority, useless p.o.s.. SCREW QuArK for only knowing how to handle builtin Steam apps, and not mods in the SDK, and for not having something resembling a decent retexturing tool.
Surprised Sad
So wait, freebuild will support Quake 3 maps?! That's f@#$ing sweet!
DShiznit wrote:
So wait, freebuild will support Quake 3 maps?! That's f@#$ing sweet!


All of these: http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/Plugins (plus the BSP plugin also supports Valve).
elfprince13 wrote:
DShiznit wrote:
So wait, freebuild will support Quake 3 maps?! That's f@#$ing sweet!


All of these: http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/Plugins (plus the BSP plugin also supports Valve).
Woot Solidworks can output into some of those formats and thus I'll actually be able to make models for Freebuild, hotness.
KermMartian wrote:
Welcome back, Xyno. It means you need a decent card to run it at decent speeds, and a good graphics card to run it at excellent speeds.

So it'll run just like TOB does now? Because if I'm lucky, i can only get 7-15 FPS, but if im on my mom's comp, I can get 50-60 FPS... (and i can rarely ge ton hers...)

i guess im just gonna have to buy a better computer...
Xyno76 wrote:
So it'll run just like TOB does now?

On low end computers it should run moderately better than TOB does now (depending on your current processor speed vs your current GPU abilities) because of the improved rendering architecture. On anything even reasonably modern it should scale MUCH better to large scenes by taking advantage of modern GPU features that aren't available to TOB.

On a side note, if you only get 7-15 fps now, you will be VERY sad when you have to play anywhere with physics.
elfprince13 wrote:
Xyno76 wrote:
So it'll run just like TOB does now?

On low end computers it should run moderately better than TOB does now (depending on your current processor speed vs your current GPU abilities) because of the improved rendering architecture. On anything even reasonably modern it should scale MUCH better to large scenes by taking advantage of modern GPU features that aren't available to TOB.
I find that last sentence extremely exciting. I hope you're right; have you verified this with something like Cemetech Towers, or am I jumping the gun on your conversion process?
KermMartian wrote:
I find that last sentence extremely exciting. I hope you're right; have you verified this with something like Cemetech Towers, or am I jumping the gun on your conversion process?

Jumping the gun. But the fact of the matter is that things like geometry instancing, vertex buffer objects + glDrawElements, and state-sorted render bins are all designed to dramatically reduce the amount of work the GPU has to do. Temporally coherent GPU-backed occlusion culling algorithms like CHC++ are also designed to reduce the complexity of the rendering and the overheard of hardware occlusion queries.

I can't believe that if I do even a mediocre job of using these techniques and the power of the OSG library that I will get worse rendering performance than TBM/TOB, and this isn't even looking at the network performance gains of basing our brick class on event-driven network updates instead of a tickable class.
Yeah, I figured I was, but that is still most excellent to hear. I think that event-driven network updates are going to make a huge difference, too.
KermMartian wrote:
Yeah, I figured I was, but that is still most excellent to hear. I think that event-driven network updates are going to make a huge difference, too.


I'm sure it will help too, especially on the truly enormous builds, but honestly it wasn't even a blip on the radar compared to the magnitude of the problem with the rendering pipeline when I was profiling the bottlenecks in Cemetech tower. I seem to remember that TSMesh::render() was taking over 60% of the CPU time.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 13
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement