Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tuxu]

The render above ground are superb however i terribly miss the way that the old visualizer by Baboonanza used to show my underground levels and elaborate tombs.
This one differs in the sense that it doesnt show the two sides of a room\compartment as the old one did, the old one had a way of interactivly culling the Z levels from below and above so the user would be left with the layer he care to take screen-shots of.
It was also a great tool for planning and analysis.

For me it also functions like WC3 cinematics did, a neat graphical reward after a long period of "hard work".

Anyhow, these are just the thoughts of a sole person who's also wants to say thank you for all of your hard work on this project.

Keep it up.

[thewonderidiot]

Hey, thanks for the input! I'll definitely keep that in mind though. Z-level pruning will more than likely be in the next release, depending on how exactly geometry ends up getting generated. Should be pretty easy to do though. I didn't put any time into stuff that allows for cleaner visualizing of underground things in this release, since, to be honest, there's not much to see down there right now.  The focus for all of the releases so far have been for mostly above-ground stuff. Now that we're cleaning things up and actually fleshing out the application, instead of piling more features on our hacked-together demo of a release, the underground stuff should be much more lively.


So, progress update. Still getting slaughtered by school work, and have been scrambling to find time to get work done for my part-time job. In what little down-time I've had though, I managed to finish the threading stuff (the core engine is now pretty much completely thread-safe) and minimize the hardcoded GUI as much as possible.

Here's what the title screen GUI script looks like:

Code: [Select]

local system = CEGUI.System:getSingleton()
local wmgr = CEGUI.WindowManager:getSingleton()
local cursor = CEGUI.MouseCursor:getSingleton()
local imgman = CEGUI.ImagesetManager:getSingleton()

imgman:create("TitleScreen.imageset");

local root = wmgr:loadWindowLayout("titleScreen.layout")

system:setGUISheet(root)
cursor:hide()

function statusBoxUpdated(e)
local statusbox = CEGUI.WindowManager:getSingleton():getWindow("Root/StatusBox")
local str = statusbox:getText().."\n"
local status = tolua.cast(Overseer:getSingleton():getCurrentState(),"TitleScreenState"):getStatus()
if status~="" then statusbox:setText(str .. status) end
end
The only line of code that actually involves the GUI at all in the title screen C++ file is this:

Code: [Select]

overseer->getGUIManager()->executeScript("titleScreen.lua");And that hard-coded string of "titleScreen.lua" will likely be abstracted to a config file by the time the first release rolls around. All of the GUI on the screen is defined in the titleScreen.layout XML file, which also tells the status box it creates to call the statusBoxUpdated lua function every time it is updated (once per frame). The title screen state itself has a (thread-safe) status queue that it pops a message off of each time getStatus() is called, or returns an empty string if there isn't a status to be displayed.

I don't see anything with the GUI changing much (if at all) before the first release, so this is pretty much exactly how the GUI for the main visualizer itself is going to be implemented, though it'll likely be a bit more involved.  Anyways, it should be extremely customizable.

Now that I've got the threading working completely and the GUI stuff pretty much done, I'm going to pass over the geometry generator for now (I might temporarily hack in the old one) and get the item support working. The config files (which model to use for what by default, etc.) will probably come with this. I'll probably have a few screenshots of this stuff working soonish (within the next week or so), but don't expect anything too fancy yet. 

EDIT: By the way, I forgot to mention something. The lua scripts won't be confined to the GUI, though in most cases the GUI will be their entry point. All of the scene management stuff that I code in the main visualizer will be public and accessible from lua, and I plan on making all of DFHack accessible from lua as well. This means that it'll be possible to script in completely new functionality through the lua scripts.  This way, nobody has to get their hands dirty with scripting, since all of the core functionality will be utilized in the default GUI scripts. However, for those people who do like to hack around with stuff, it'll be a lot easier than trying to get the C++ stuff and all of its dependencies to build.

[Jeoshua]

Is it possible to make the polys double-sided? So that I can fly around "inside" the ground and still see where the walls are?

[thewonderidiot]

Is it possible to make the polys double-sided? So that I can fly around "inside" the ground and still see where the walls are?

Yep, find the three Parent material scripts in materials/scripts/ and in each add the following to all of the passes of the technique you are using (default is basic, at the bottom):

Code: [Select]

cull_hardware none
cull_software none
For example, doing this to the basic technique in constructedParent.material would look like this:

Spoiler (click to show/hide)

Code: [Select]

technique basic
{ lod_index 4
   
pass ColorRendering
{
  ambient .75 .75 .75
  diffuse 1.0 1.0 1.0
                  cull_hardware none
                  cull_software none
texture_unit MaskingColor
{
texture constructed.png
  colour_op_ex blend_texture_alpha src_texture src_manual $maskingcolor
}
}

pass MainRendering
{
ambient .75 .75 .75
diffuse 1.0 1.0 1.0
                 cull_hardware none
                 cull_software none
scene_blend modulate
texture_unit ColorMap
{
texture constructed.png
colour_op add
}

}
}

That should work. I guess Ogre material scripts aren't the most readable things in the world, so I'll add a backface culling toggle to the GUI in the next release.

[Jeoshua]

Yeah, cause I would have figured that would cull things BEHIND a wall, not the back-face OF the wall... subtle diff.

[Ethicalfive]

I think blender uses blender units. Which are not a real measurement. Converting from sketchup to blender does make for some gigantic models, but it's simple to scale, so I don't see how it's an issue at all.. I mean, your going to have to clean up the model likely after importing anyway right?

This is what I was referring to - SketchUp handles decimals of measurement units differently than Blender, so Blender winds up thinking that there are many more full-sized measurement units than SketchUp does. Sorry for being confusing. 

Is it simple to scale a model in Blender? I can't figure out how. I can't figure out how to do most things in Blender. Every time I try to use it I feel like I'm being slowly sucked into an whirlpool of gibbering insanity.

Oops, missed this one. Select your object(right click on it) then press the 's' key to scale. You can enter in an amount to scale by also after pressing s or go by eye. If your editing the object (tabbed in) then make sure you press 'a' and select all your vertices first.

Blender is alot like DF in a way, has some hard to learn shortcut key layouts and hard to navigate interface, but it's designed to help better streamline 3d work, once you learn all the keys, you can blaze through a model in no time. Theres some good video tutorials floating around that can greatly help with learning how to use it.

[TerryDactyl]

Yeah, I just got my video drivers updated and I'm still getting that blasted skydome error. Using lenovo m55.

[Ghills]

I think blender uses blender units. Which are not a real measurement. Converting from sketchup to blender does make for some gigantic models, but it's simple to scale, so I don't see how it's an issue at all.. I mean, your going to have to clean up the model likely after importing anyway right?

This is what I was referring to - SketchUp handles decimals of measurement units differently than Blender, so Blender winds up thinking that there are many more full-sized measurement units than SketchUp does. Sorry for being confusing. 

Is it simple to scale a model in Blender? I can't figure out how. I can't figure out how to do most things in Blender. Every time I try to use it I feel like I'm being slowly sucked into an whirlpool of gibbering insanity.

Oops, missed this one. Select your object(right click on it) then press the 's' key to scale. You can enter in an amount to scale by also after pressing s or go by eye. If your editing the object (tabbed in) then make sure you press 'a' and select all your vertices first.

Blender is alot like DF in a way, has some hard to learn shortcut key layouts and hard to navigate interface, but it's designed to help better streamline 3d work, once you learn all the keys, you can blaze through a model in no time. Theres some good video tutorials floating around that can greatly help with learning how to use it.

Thanks! I'll try that.

Does anyone know what scale I should be aiming for?

[thewonderidiot]

When you export Ogre mesh .xml's from blender, it usually does 1 blender unit = 1 ogre unit. The current release of overseer has 10x10 ogre unit tiles. So that's a starting point. We can always scale the models to the proper size later if needed.

Yeah, I just got my video drivers updated and I'm still getting that blasted skydome error. Using lenovo m55.

That's really weird. Can you give me an exact graphics chipset? If you're using integrated graphics, how well does it play newish 3D games that use shaders?

[Ghostbird]

This answer has probably been answered earlier in the thread, but I'm too tired to read it entirely, and the search function doesn't work for threads.

Is it possible to compile Ogreseer on Linux systems?
If so, will you put the source up for download?
If you need help testing Ogreseer compile and run on Linux, I'd like to help. (Like I did with the Overseer Linux version) In a week, I've got third quarter exams this week.

[thewonderidiot]

Is it possible to compile Ogreseer on Linux systems?

The answer is a resounding maybe. The limiting factor before was the shaders in some of the libraries we used. Sexymustard got it working in OpenGL on his computer, but it still refuses to run on my computer. There's some windows-specific code in the initialization code too, but it won't be a big deal to slap some preprocessor stuff around that and throw in a linux equivalent. I'll have a chance to look at this stuff more during spring break next week.

[TerryDactyl]

I'm not sure. I only play Dwarf Fortress.
 

Q965/963 Express Chipset.

Looks like I'd better focus on migrating the rest of my settings / hardware / files from the old computer, soon. If it's affecting my game, then it's affecting photoshop and my work, too.

[thewonderidiot]

Q965/963 Express Chipset.

Well, there's your problem. According to Intel's website, the Q965 chipset only supports up to shader model 2.0, which, as I said, is almost a decade old.  Our minimum requirements are 2.0a, I think (there's actually a very large difference between these two). I'm not entirely sure we'd be able to get everything working under pure SM2.0.

[TerryDactyl]

Well, carp.

Sorry t'bother you, mate.

[thewonderidiot]

Well, carp.

Sorry t'bother you, mate.

It's cool, don't worry about it.  Sorry we don't support your chipset.

So, in other news. I've been coding like mad all weekend, but all of it has been for work. Haven't touched the Overseer codebase. HOWEVER, I have done a lot of thinking about how the item system. Specifically, how to store the model configuration. Since I want models to be swappable (individually as well as en masse) in-visualizer, it'll probably store all known models for each item under that item in an XML file, with the default to be used marked. There are two problems raised by this: first, with the sheer number of items in DF, there's a chance that this can get pretty tedious to edit pretty fast. Especially if somebody makes a "set" of models that have similar themes. Second, multiple possible models per item would also exponentially increase the download size.

Both of these problems can be solved by having model 'packs' that can be downloaded. There's still a problem there, though... merging two packs would be quite a chore.

So here's the thought. I'm thinking about making a package manager for Overseer. When you download a package of models or textures, you would be able to install it by opening it with the package manager. The package manager would merge the package's config files into the main Overseer files and lay out the new files and folders as nicely as possible. You'd be able to set the new package as all defaults, no defaults, or possibly even manually merge -- the newly installed model or texture would be displayed side-by-side with the current default and you'd be able to click on which one you want Overseer to use as the default model/texture.

Taking a step even further back, it wouldn't be too much more of a stretch to set up a repository of these packs, so the package manager could just go out and grab packs you select to have installed, and then it would be able to download and merge in everything. Maybe if you select 4 packages with the same item in them, the merger would display all four plus the current default and you can select which you like best to be set as default.

Anyways, this is all theoretical, and not at all necessarily how the final system is going to work -- but I think it's something worth looking into. I know that this is a lot of overhead for a visualizer I'd like to hear what you guys think though.