Topic: Discussion on Models

[[UFP]Exeter]

Yes, it will have to wait.  Depending on work I will acquaint myself with most things then start on it.  The issue will be shaders, that was a dramatic change.  The shader pipeline is giving some of the developers of Irrlicht issue.  But that are trying to take existing code to DX11 and have it operate the same.  But we will not have that constraint.

If you can document what you want I can keep it in mind.  A nice smaller program to test our engine.

[Starfox1701]

Ok that will take some time. I'll get something together.

[[UFP]Exeter]

No rush, have alot to do to get there.

[[UFP]Exeter]

I am impressed.  In DX11 the removed the D3DX library for math and replaced it with he XNA developed math library that includes support for special hardware registers.  SSE2, 128 bit wide SIMD.

This is impressive, Vector math calculations can be 4 times faster this way.  This will really speed up model changes such as scale, rotation and translation.

[Starfox1701]

That's good news. Are you familiar with the Nano FX model viewer?

[[UFP]Exeter]

Never looked at it.  The NanoFX  (and Nano FX GRE?) merged into Excalibur about 3 years ago.  Then it was DX 9.  Not sure if the upgraded to DX11 or not.  The viewer is for Excalibur models and I have no idea of their model format.

I tried find out more about it but ran into dead ends.  Other than they use the NewtonDynamis Physics Engine, not Bullet.

[Starfox1701]

Yes it represents a very early form of the Evolved engine. The important point is that it represents a good example of at least the basic functionality that a model property editor integrated into the game engine would need. What do you think of using it as a model to pattern our Model property editor on when the time comes feature and function wise using our engine, physics, an UI?

[[UFP]Exeter]

I have no problems with that.  Do you have a copy of it?

[Starfox1701]

yea you can still download it here

http://www.moddb.com/games/star-trek-excalibur/downloads/model-viewer-v17

[[UFP]Exeter]

Thanks, but to do it I need to understand the hotpoints and models.  Does not make sense to me.  For realism a phaser beam should come from the "hotpoint" on the model and go in the designated direction using ray cast to see if it hits a target.  That means the program needs to know the location of the hotpoint relative to the model center.

[Starfox1701]

That's why I suggested using the viewer as a guide. On of its features is it lets you hardpoint the model. This version uses .X file format models like we are planing to. all the files are presented in a format that can be edited from note pad or Wordpad or directly by the viewer. The Hardpoint is recored in the HP fiie. In the case of the stock vewer theres a Galaxy class mode, the SNS Galaxy. The Hardpoint files is here Release 1.7a\Gfx\Models\Federation\Ships\Galaxy\Scripts and is named Galaxy and Galaxy_HP. There is a model conversion tutorial in 6 parts here with more info

http://www.youtube.com/user/24thCenturyBuff/videos

Did that answer you question?

[[UFP]Exeter]

close enough.  The hardpoints are identified somewhere, that is what I need.  I just looked at the file, and I take it that is not part of the dx standard but their graphics engine.  The .x models I worked with before did not have a script file.  That tells me the hardpoint data can be in anu text file and related to an model format.

I mentioned I do not want to support just X format.  Maybe prejudice but I am NOT a abit fan of microsoft.

[[UFP]Exeter]

Been doing some research.  Here is a thread about Irrlicht and DDS for textures:   http://irrlicht.sourceforge.net/forum/viewtopic.php?p=149805

I did find source to read a DDS file, also Google Chrome is open source and has a dds loader.

It looks like Irrlicht 1.9 is progressing nicely, I pulled the code from SVN, and as far as what i am using right now everything works great.   The DX11 drivers are not finished, for the shader pipeline but I do not need that quite yet.  Everyting else works and I test my working code against DX11 and it works.

I think we should proceed with Irrlicht and if we need a DDS loader, I will add it.

It is Beta but stable enough for now. 

[Starfox1701]

Definitely understandable. Will it complicate things to support other file types? In game, at least for our project, we need to pick a single file type that combines the best speed and graphics and use that one but I have no problem with the engine being able to use other types. So the question is are .X files the best for the job or is one of the other DCC formats better suited? Also would it be all that hard to create a file format for our engine specific to it?

We will need a .DDS loader as they are the best texture option. .DDS files basically come with built in LODs and save processing power as you pull away from the object.

[[UFP]Exeter]

We can disable any file type we do not with to support.  And we can add our own filetype, a custom one.  But, for modding, why not just support some good standard ones that makes it easier to mod?

I do work on multiple items at once so now I can work on the physics and start planning the AI.

As for irrlicht it allows me to support either dx 11 or 9, or Open GL 2, so changing the configuration to allow user selection.  This was already coded for DX9 and OpenGL, added DX11 and it works so no deed to rebuild the code to change drivers.  And users on older systems can drop to DX9 with notepad to change the driver in config.xml

[Starfox1701]

If you can make it work go for it. I suspect though that these other files will lag in performance in the engine. As far as the moding goes though if we have importers and exporters for the most common DCC programs it shouldn't complicate things as all the Hardpointing would be done in the Model property editor regardless of file type.

[[UFP]Exeter]

When I started this long ago, I had a backup for every library.  The backup was to do it myself, but I had hoped the libraries all performed well.  So if there are performance issues we step back and fis that area.

Our code will be optimized for DX11, but this allows those who need DX9 to play the game, but at reduced performance.

We can use the model property editor as you say, but I am concerned out those that cheat.  So I think the maximum hotpoints per class/race should be coded in the database.   Then they can do what they want, but they cannot arm a frigate like a battleship.   A Sabre with the firepower of  Sov would be something to see though.

[Captain Adam]

.

[[UFP]Exeter]

No, modding is one of the core features.  However, there may be some limitations, as the game play and the core specs of ships are gear will not be.

But anything can be changed.

[Starfox1701]

I don't think that will be necessary. The need for multiplayer sink will keep players from using godships PvP unless both sides agree to it. On anything like a dynaverse server only the approved version would be allowed to log on by the server package. If some one wants to cheat in the single player mode that's on them. We don't need to police the single player mode so long as these other safe guards are in place. I would imagine simpler to code in the long run too.