Print

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

[Skeggox]

To those worried about polycount, remember that there are maaany ways to work around it.

Firstly, you use LOD models - the LOD stands for Level Of Detail. Simply put, you take a model of a barrel with high detail (6k polys) and create successively lower detail versions, up to a certain point (say, 100 polys). The engine then chooses which model to use, based on camera distance. So if you are zoomed up close an personal to a food stockpile, the high-detail versions will be used for graphicy goodness, and in an outside scenery shot the very low count barrels will be used.

Secondly, modern GPU's provide the ability to do instancing - that is where you load a set of meshes and textures (i.e. a model) into the graphics card's memory, and then you load up a list of positions, scales and orientations. The GPU will then use the same model, but just render it X number of times using hardware. This cuts the time spent transferring data between main memory and graphics card, which is often the speed limiting factor.

Lastly, there is a technique called imposters - where you render the model to an offscreen surface to get a 2D sprite (a transparent thumbnail picture), which you then 'stamp' wherever the model appears far in the distance. So the cost of rendering the model then becomes drawing a single quad (two squares). That is the technique VF uses for the tree models - you can see that after a certain distance the trees' appearance change somewhat, looking more 'flat' than usual. The Total War series of games relied heavily on the imposter system as well - otherwise it would be impossible to render 5k+ troops. It explains the spritey look of the soldiers in the early games from that series.

AFAIK OSG supports all three techniques mentioned above, so I am really not worried about performance at this point.

Remember that a big part of Obsidian is its planned ability to export to common raytracing renderers (like Povray, Blender etc.). So we'll eventually need a high-detail raytrace and lower-detail real-time version of each module (and texture?).

[cephalo]

If you would, go ahead and release a basic version as early as possible. Don't even worry about different stone types initially, just get the shape. We have no 3d visualizer! I just embarked on a large extremely epic site, and I would so have liked to see a basic overview so I can maximize it's potential. Stonesense isn't so useful for getting a site overview. Now I'll have to mess it up by working blind!

[Askot Bokbondeler]

i've got a little sugestion for a feature, could you make an *adventurer view* where we could explore the fortress in a first person view?actually walking on the ground, instead of flying arround, like some visualizers did

[Retro]

i've got a little sugestion for a feature, could you make an *adventurer view* where we could explore the fortress in a first person view?actually walking on the ground, instead of flying arround, like some visualizers did

One step at a time now, we don't even actually have a 3D visualizer yet But yeah, that'd be a cool feature, and a new one to the community.

[Dwarf]

post 4 watch

It'd be nice if Obsidian includes mac compatibility, but I guess it's not a first priority goal, if one at all

[Crunch]

i've got a little sugestion for a feature, could you make an *adventurer view* where we could explore the fortress in a first person view?actually walking on the ground, instead of flying arround, like some visualizers did

Great minds think alike, apparently.  It's not the first priority, but 2 days ago, Skeggox did say:  "There will definitely be a FPS-style walkthrough capability, so you can wander the bloodsplattered halls..."

[Askot Bokbondeler]

awesome! even better would be to eventually link that feature to adventurer mode

[Sizik]

so you can wander the bloodsplattered halls..."

I hope blood (and other) splatters are eventually implementes.

[Djohaal]

For the barrel try to simplify it into a tapered curved cylinder with some smart bump mapping instead of bent boxes, that is way too much detail for a simple barrel, even with progressive LOD.

So... I take it you're not gonna like my higher-detail version, complete with modeled knotholes and small polygonal splinters?   

It will be nice to downgrade to a tapered cylidner. What I mean is that having many separate sub-objects (the boxes, braces and etc) is a waste of performance. The best way of doing it is a tapered cylinder with extruded braces and good bump/normal mapping, it saves a lot of fuzz since it is a single mesh.

I'm slowly syncing back to E-life, however I still have one week of lab work to go and some post-traumatic stress from the exams week, so... 

[Skeggox]

It'd be nice if Obsidian includes mac compatibility, but I guess it's not a first priority goal, if one at all

I'm using CMake, and all external libraries are open source and Linux-based, so there should theoretically be no reason to not have both a Mac and Linux version as well. Once I'm in a position to start releasing, I'll look for Linux and Mac volunteers that know their CMake and programming to get those two platforms up and running.

To speak the truth, I'm very likely to switch over to full-time Linux development of Obsidian soon. I'm getting my fill of Windoze at work, and although Mingw32 tries, it just ain't the same as a good Archlinux system.

I haven't tried Mac development yet (but my lady has a Powerbook and I can always sneak it away from her whilst she is reading and try my hand at it), but AFAIK Mac OS X is basically a Unix system, so the "porting distance" between Linux and Mac OS X should be less than between Linux and Windoze.

In that case I'll be needing volunteers to keep the Windows/Mingw32 platform maintained

(And good luck to them - I already have at least 10 packages that needs to be custom installed in windows: libxstl, libxml2, libiconv, libzip1, OSG, OpenThreads, DevIL, Lua5.1, log4cplus and freeglut)

[Skeggox]

Progress Update

Alas, I have little progress to update today. I'm finalling at work for the next 8 weeks (we release in mid October), so I'm looking at 10-14 hour days. I only get about an hour each day to spend on Obsidian, and it is hard to get flowing in such a short time.

So during the week I'll be tweaking and cleaning up existing code, and on weekends I'll be tackling big stuff, like the terrain generator, etc.

That doesn't mean I haven't made any progress - in fact, I've got the Cell engine to properly load and save from DF 31.0.08 to XML using the latest DFHack library.

I've uploaded a cell file for my current Nurembourg-style castle project: http://dffd.wimbli.com/file.php?id=2573

I'm currently packaging the cell engine as a stand-alone Lua module, for anyone that wants to play with it whilst I continue to work on Obsidian.

[Cruxador]

I'm currently packaging the cell engine as a stand-alone Lua module, for anyone that wants to play with it whilst I continue to work on Obsidian.

For those of us who aren't so good with computers, what does that mean? Is that code that only people with significant Lua knowledge would be interested in, or a functioning utility that we could use, or, as I would guess, somewhere in between?

[Draco18s]

Lua is a scripting language that is used by a lot of programs, so its pretty standard.  But I don't know how to code in it at all...

[Ratbert_CP]

Lua is actually pretty simple.  If you have experience with Javascript and/or Perl, you should be just fine.  FWIW, the WoW API uses Lua (which is where I learned it)...

[Cruxador]

I know what Lua is. I was asking what this specific package is.

Though if Lua is similar to Javascript, I might be able to figure it out since I used to know Javascript.