Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

3D World Studio / DBP 3dw Importer Underway

Author
Message
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 12th Dec 2007 00:13
Link
Have started work on Tireswing's 3DWS Loader code today as it's already coded as a C++ Class and as such should take a lot less conversion effort, although it is utilising a few Irrlicht specific classes, templates and typedefs which I'm having to convert.

It will still require all the code writing to take the parsed data and build the DarkGDK objects so I'll be relying on your code and techniques to guide me! It may not prove viable but I thought it was worth an initial shot as it might cut down on overall time taken to port your code in its entirety.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 12th Dec 2007 02:07
Link
Cool. I have considered doing something similar when I port it over to the DGDK.net. I think I am going to just use Visual BASIC, but I may relearn and use c++. I'm a BASIC kind of guy really. I found another bug in the mesh lighting today. Will try to sort it once and for all tonight. I'll post what I end up with either way. It seems that not only does he put the limbs in the wrong order, but also the polys of the meshes.

Back to top
Profile PM Email
jason p sage
18
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 12th Dec 2007 03:24
Link
Ouch. That MIGHT explain something I ran into with it recently. I made a Airport Tower - and used the cinder block textures inside - and the "Corrugated" metal outside. Picture a simple "Rectangle - three faces have one texture - 1 face another. I load the exported Direct-X into DarkGDK (C++) and any "Primitive" with two textures - ends up with a diagonal line across it - where one triangle is one texture and the other triangle is the other.

If I use one texture for the whole primitive - problem goes away - but that means I have less "creative freedom"

Could just be the Direct.X Export - - I'll know when I see some of your finished work guys - but for now - I'll use that method - even if I'm forced to make a few extra unwated poly/primitives to get the look I'm shooting for - shoot - in this airport case - it kind of kills the nice interior I was shooting for - I may just turn the tower into one primitive - and make the "door" locked -


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 12th Dec 2007 04:08 Edited at: 12th Dec 2007 12:44
Link
My importer works with terrain and brushes pretty good as far as I can tell. The brushes are spot on from all of my tests, but the terrain is a bit darker than in 3dws. I may have a go at correcting htis later.

I'm just having trouble getting the mesh lighting info organised from the 3dw format. You see it doesn't save anything from the original mesh but the mesh file name, the number of limbs in it, the number of verts in each limb, and the vertex color of each vert in each limb for lighting. Nothing about how his engine loaded the file to get the limb or vert order. DBP loads the files backwards from 3dws as far as I can tell. The limbs are in reverse order, the polys in each limb are in reverse order, and I'll bet the 3 verts per each poly are in reverse order as well. It also has ghost limbs for the meshes that have 0 verts and textures not even used in my maps in the mesh listing. Hopefully I'll know more about it tonight.

Once the mesh lighting is sorted, I'll have a very quick go at brightening up the terrain a bit. Then I'll be asking suggestions about how people think the entity system should work and compare that with my needs. Then I'll finish off the entities and it'll be pretty much done for full beta testing.

I can also make a version that doesn't use the shader file for the brush lightmapping, but it will increase the limb and overall object count as DBP doesn't have a set limb blendmapping mode or a blendmapping command that uses the textures already on the limbs.

[edit] I am extemely P.O'd at the 3dw file format at the moment, so I am going to bed. I found the error and it spells trouble for universally lighting meshes. In some meshes the polys are triangulated and others they have face data or quads. The problem is that there is such a mess with everything being in reverse orders and what not, that it is hard to tell which is which as DBP loads almost all models and triangulates them. Yet some it doesn't. And furthermore, I don't have a way to create an object with face data in DBP. I can only create triangulated ones from memblocks. Here is my latest code that seems to work well with triangulated models here (except of course like the terrain ... the models are darker than in 3dws): DBA file attached due to Rich's limit on the post length.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 12th Dec 2007 20:24
Link
Hmmm ... two steps forwards ... one step back! Might be worth talking to Josh again ... see if there is any method to his madness!

In the meantime I'm pressing on with the C++ 3DWS Loader class conversion but I stopped to try out your latest code. See the screen shots attached to this post but it seems to have screwed up the transparency on my trees. The first shot is the previous incarnation of your loader with the second one your latest! The weird thing is both the trees and the ferns use a .png texture with the transparency set to 0,0,0 but the ferns seem perfectly ok!

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 12th Dec 2007 22:12
Link
Weird, it seems the vertex coloring may be over-riding the transparency. Also in 3dws I noticed that there isn't any actual coloring on transparent meshes here, even if you check transparencies to be lightmapped. Try this function (though you won't be able to use png textures on non-transparent meshes if you want the lightmapping):



Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 13th Dec 2007 00:51
Link
Well I have got the 3DWS Loader Class to the point where it compiles in VC++2008, so next stage is some testing to see if my replacement classes and member functions are working and if it looks like it's parsing the files correctly.

I tried your replacement function setup_meshs() but I'm still getting transparency problems. New screen shot attached. It looks like the whole of the trees including the transparent areas are now covered with bark texture???

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 13th Dec 2007 04:06
Link
I'll double check it tonight. I don't remember changing anything in the texturing or image loading, but I was quite sleepy and aggravated while messing with it.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 13th Dec 2007 10:49
Link
Sounds like you could do with a couple of days off from this and unwind a bit. This kind of work can get really frustrating at times. I'm in no hurry for the fixes, I'm just providing a bit of independent testing and feedback for you as I know how important this development will be to myself and the rest of the DBPro/3DWS community.

I wish I could help more, but to be honest my understanding of the low level workings of polygonal modelling is minimal to say the least although I'm learning as I go along.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 13th Dec 2007 11:51 Edited at: 13th Dec 2007 11:55
Link
I accidently reversed the limb ordering back to normal order it seems while messing with it. Try this function that reverses it again:



The only thing right off I can think of is it is texturing the wrong limb with the wrong texture.

As far as the time off from it ... I don't get much done on it now as I only get to work on it after work in my spare, spare time as it is. I have come up with a number of solutions for the mesh lighting errors in my head though (at least until the next version of the file format comes out):

I can do away with .x support altogether or do lightmapping on triangulated models only (the vertex counts would not be equal per limb on quad models). I can then write a .x to .smf converter (which 3dws may have with it) and load the .smf files as I would then have the quad index list from the smf format. And I could then write the .smf loader. I have the index list for the .mesh files in my loader code for it, so I can make it work. However not everyone has the .x and .smf to .mesh converter (its bundled with the leadwerks engine sdk) or the .mesh plugin that allows 3dws to load the .mesh files (comes with the engine in the developers section of his site).

Or I could do away with .mesh and .x file altogether and write a converter for them to .smf and just use that format. I'll get back with Josh if he will answer my email and make sure he's not gonna do away with .smf support in 3dws and just move over to .mesh since it is his engine's primary format. If he'll make the converter and plugin available to everyone I would just use the .mesh format for the importer.

In any case it's late and I'm off to bed. I had to work late tonight.

[edit] Must be really sleepy ... forgot to finish my post. Thanks for testing this as I am not a level maker or modeler myself I have very limited testing levels for now. It's helping out alot, else It may have been a while before I caught that texturing bug and such as it worked with my few test levels.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 13th Dec 2007 15:54
Link
That’s worked a treat. Thanks LIT. All the trees look like trees again! Meshes are all looking very dark but increasing the ambient lighting adjusts for that. I think you have changed the transparency mode on the mesh textures, looked like it was previously 4 and is now 1 or 2. I wish we could change the transparency settings on individual limbs, as I think you eluded to in a previous post, as I could then dynamically switch modes to get round some of DBPro's alpha limitations. For trees and vegetation 1 or 2 are better at a distance but 4 is better close up.

By the way, is Josh's engines .mesh format the same as the OGRE .mesh format or is it a proprietary format unique to him?

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 13th Dec 2007 21:47
Link
Glad it's kind of working for you again. Actually with IanM's matrix plugins you can set the fvf and transparency modes per limb. I may have a look at this myself later:

Matrix1Util_12 1.1.0.1
- Added SET LIMB TRANSPARENCY/GET LIMB TRANSPARENCY commands
- Added CONVERT LIMB FVF command

As far as the meshes go Josh says to just load .x and not .mesh now. But he told me to use .mesh and not .x before. But since I can't tell how 3dws loads .x models accurately every time, this is out of the question until he changes the format. Or I come up with a better solution (which is not looking too good so far).

So I guess the answer will have to lie with the .smf converter/loader option. I wish I hadn't wasted so much time on the .mesh stuff now

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 14th Dec 2007 00:05
Link
That's really interesting about IanM's pluggin, I didn't know about that! As soon as I get some spare time I'll try that on my engine and see if that fixes my transparency problems with .dbo loaded levels!

In the meantime, I've added code to load the 3DWS file into memory and am about to start testing my amended version of Tireswing's 3DWS Loader to see if its successfully parsing the file. All being well I should hopefully start on the member functions to create the DBPro objects this weekend. I'm going to have to sit down and go through your code to gain a good understanding of how you are going about creating the various objects from the given data. I might be asking questions if I need any assumptions confirming or concepts explaining ... hope you don't mind!

Anyhow, back to your problems:

Quote: "since I can't tell how 3dws loads .x models accurately every time"


Can you not ask Josh to explain how he's doing this, it must be to his advantage to see this project succeed!!!

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 14th Dec 2007 00:46
Link
I don't mind you or anyone else asking me questions. I'm mostly doing this to help people anyway. You may want to contact me through email though since i use it most of the time. As you can see by the time between my posts throughout this thread ... I don't always get time to check the forums. I do however always try to find time to help people that contact me through email. I may not always get right back with you, but I'll be checking on it.

Quote: "By the way, is Josh's engines .mesh format the same as the OGRE .mesh format or is it a proprietary format unique to him?"


I don't know the answer to that, but since he first recommended I use it ... I would think it is more open. ¿

As far as my problems with the importer ... I had another idea in my sleep last night that may fix the problems even easier, though will decrease the FPS just a bit.

I could go on with my plans for the smf converter and loader, but I could also write a triangulator code for .x models. The .smf (simple model file) file format itself seems to be open format as I can find data about it all over the net. This would allow you to take your non-triangulated .x models and triangulate them. You could then use these models in 3dws and I could easily match up the info in my importer. Only non triangulated models seems to be the problem.

Either way my bro is making me a huge test level for me to play with, so it may be easier for me to find bugs and fix problems. Lack of variety and test levels have been holding me back a bit. Also if anyone has any problem levels they would like me to try and make the code work with send them my way. I'll delete them when done along with any textures or models you send.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 15th Dec 2007 00:09
Link
Thanks LIT. I'll try to keep any questions to a minimum as I appreciate how busy you are.

With regard to the x file conversion to smf that's cool with me! Glad to hear your Bros helping out with the test level too .. will make a difference being able to get instant visual feedback on changes you implement.

Quick update on my progress with Tireswing's 3DWS Loader. I now have it successfully reading my test level file and the parsing seems to be ok ... its running without any errors and appears to be creating all of the data group classes labelled and pointing to the offset data in memory. Of course I wont really know until I start creating the DarkGDK objects themselves but its looking hopeful at this point! I'm still on target to start work on that this weekend which is where your code is going to play a big part. Not sure how much I'll manage to get done though as it's close to Christmas and I have family commitments.

I have to say that I'm really impressed with the OOP code that Tireswings put together to parse the files .... very nice!

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 15th Dec 2007 05:10
Link
Yeah with a large and diverse level I should be able to fix things alot easier. Becasue I can view it both in my importer and 3DWS itself. I had planned on doing this with Josh's Complex level, but I only have .mesh versions of most of the models he used. So I can't view it in 3DWS.

Really glad to see your importer is making progress. I will enventually be making the move to DGDK or most likely DGDK.net, so I'll probably be checking back with you on what you have done.

Does Tireswing's code deal with mesh lighting? I may have a look and see how he handled it. Although he wrote a smf loader ... so he may have taken this route. I'll have a look at his smf loading code before writing mine. Also does Irrlicht use a GL renderer or DirectX? If it uses GL as 3DWS does it may have made it easier for him to match up the data.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 15th Dec 2007 22:03
Link
Tireswing quotes the following at the top of his main routine:

Quote: "
This example loads a 3D World Studio File directly into Irrlicht.
Currently, it loads:
- Brush Geometry w/lightmaps and textures
- Referenced Meshes (.X and .SMF only -- loads prelit vertex colors for .SMF meshes, but not .X)
- Entities (will create ILightSceneNode's for each light entity if desired)
- Terrain (currently only uses the first layer and lightmap)

TO DO:
1. Load prelit vertex colors for referenced .X meshes.
2. Write a shader to enable
3. Create a custom scene node for a 3DWS scene and rewrite loading functions to implement the IMeshLoader interface.
"


With regard to Irrlicht and rendering I believe it supports both Direct X and OpenGL as it supports multiple platforms.

I haven't done any more with the loader today as I'm concentrating on going through your code so that I fully understand what your doing before coding the next stage.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 16th Dec 2007 03:48
Link
Quote: "loads prelit vertex colors for .SMF meshes, but not .X)"


That is what I thought. He has the index list from parsing the smf files I have decided to go ahead with the .smf loader and a .x to .smf converter. I can create the converter without even parsing the .x file with DBP's commands, so I won't have to learn all the vast .x formats. Then people could just do away with .x altogether in the long run.

I'll probably still come back and work on .x model lighting later, but it will be on the back burner for non-triangulated models.

Quote: "I haven't done any more with the loader today as I'm concentrating on going through your code so that I fully understand what your doing before coding the next stage."


Good luck with that. The code was written in a terrible state really with the extremely limited amount of time I had to work on it. I'll come back and clean it up and optimize it some more when I have everything working. I'll be offline for most of the weekend, but if you do have any questions just email me. I'll get on every once in a while.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 17th Dec 2007 00:07
Link
Don't think I'm going to get much more done between now and Christmas other than finish reading through your code as I'm extremely pushed for time myself now. Christmas is a family time and I need to devote some time to them!

Don't worry about your code ... its all making sense so far! My codes no more elegant and as you say, plenty of time for tiding it up later.

I'll email you if I have any problems understanding it, otherwise good luck with the smf loader and hope you enjoy the festive break. I'll let you know as soon as I have some code that displays something.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
dugzilla
22
Years of Service
User Offline
Joined: 5th Aug 2003
Location:
Posted: 17th Dec 2007 13:53
Link
Sorry to Hijack this thread but a real quick question. LIT-I was thinking of purchasing 3dWorld Studio. Can you tell me,if any, the problems with exporting(dbo)? Mainly I want to import my model's I've make in Milkshape and put into 3dworld studio and get proper shadows,then use the dbo exporter. Thanks Doug
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 17th Dec 2007 22:54
Link
From the minimal testing I have done, the only problems I have ran into are;

1) the lighting on everything is 2X darker than in 3dws. You can use a shader with mod 2x blending to fix this on everything but terrain. I have yet to find a mod 2x vertex color shader. The shader included in one of my first posts is quite fast and works great.

2) you have to calculate light on the objects or the textures won't load properly.

Back to top
Profile PM Email
jeffhuys
19
Years of Service
User Offline
Joined: 24th May 2006
Location: No cheesy line here.
Posted: 29th Dec 2007 18:01 Edited at: 30th Dec 2007 02:12
Link
Hey LIT!
Sorry for the noob question, but when I try to load my map, all textures are: NO TEXTURE FOUND... I know I had to put the maps in the texture folder, which I did. Now I have in the folder: devMaterialsMy (where the used texture is), and in dev I have my map. What am I doing wrong?

Thanks!

Jeff


You're the 'th to view this signature!
Back to top
Profile PM Email
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 30th Dec 2007 02:36
Link
The textures' folders should be in the same location as the exe for now I believe. I am going to make a media copy program that will put it all in the right place, but haven't had time yet.

Back to top
Profile PM Email
jeffhuys
19
Years of Service
User Offline
Joined: 24th May 2006
Location: No cheesy line here.
Posted: 30th Dec 2007 14:18 Edited at: 30th Dec 2007 14:20
Link
Ok thanks, that would be cool, since it does not work for me...

EDIT: It works now! Thank you!


You're the 'th to view this signature!
Back to top
Profile PM Email
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 30th Dec 2007 23:10
Link
Glad you got it working. I just hit a deer today and put my truck out of commision for a few weeks ... so I may have more time to work on this again.

Back to top
Profile PM Email
jason p sage
18
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 30th Dec 2007 23:42
Link
Sorry to hear that LIT


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
jeffhuys
19
Years of Service
User Offline
Joined: 24th May 2006
Location: No cheesy line here.
Posted: 31st Dec 2007 01:27
Link
Sorry to hear that LIT, but glad you'll be working on this again. BTW, how to make it so that when you make a map in 3DWS tat you can make seperate objects? Say, you have made a terrain, and you have some cubes flying above it. When loaded into darkBASIC, how to say that it must automatically detect what must be dynamic and what not? Thanks!
Jeff.


You're the 'th to view this signature!
Back to top
Profile PM Email
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 31st Dec 2007 07:44
Link
Well for now (until I get the mesh lightmapping finished) it creates 1 object per terrain, 1 object per brush, and 1 object per mesh. But once the mesh lighting is out of the way and I start on the entity work ... you will be able to do everything with groups. It will be like 1 object per group and with all like materials (textures) grouped into 1 limb per material or similar.

Back to top
Profile PM Email
jeffhuys
19
Years of Service
User Offline
Joined: 24th May 2006
Location: No cheesy line here.
Posted: 31st Dec 2007 16:34
Link
That would be awesome, it would be really simple to plug in to Darkphysics or Newton, or ODE!


You're the 'th to view this signature!
Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 6th Jan 2008 14:37
Link
It's a terrain Jim, but not as we know it

Think I still have a way to go lol. But at least its square, has the right textures and overall size! Just thought I'd let you know work is still continuing on the DGDK 3DWS Loader, just been a bit pushed for time.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 7th Jan 2008 06:31
Link
Glad to see you making progress. I know all about being pushed for time. I haven't hardly had time to mess with mine lately again.

Back to top
Profile PM Email
Cash Curtis II
20
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 9th Jan 2008 10:07
Link
@Lost in Thought -
How are map mesh lightmaps stored? I can't find any references in the limb texture names on any stage. For a mesh the texture is stored on stage 0, but the only thing that I've been able to do is manually apply a fake lightmap to stage 1 and have it blend with your shader. However, when I load the .dbo normally with no textures at all the meshes have lighting.


Come see the WIP!
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 9th Jan 2008 18:04 Edited at: 9th Jan 2008 18:04
Link
Both the terrain and meshes use vertex colors for the lightmapping. Only Brushes use an actual lightmap texture.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 12th Jan 2008 14:01
Link
DGDK Loader for 3DWS

Well the terrain is looking good now. Think I have that pretty much sorted. Have had some real fun and games with dynamic multidimensional arrays in C++ but I have most of what I need in place now to be able to go on and code the rest. All of the file loading and populated data structures are in place and in addition to that the material loading and the terrain creation. Next the creation of the brushes and meshes.

Snapshot of how the terrain is looking ... below. I have a good feeling about this now. Thanks for your help again LIT. It's only a question of time now!

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 12th Jan 2008 19:46
Link
Yeah man looks like it's coming together nicely Brushes are the easiest of it all, they shouldn't take long. Meshes aren't too bad except for the lighting.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 26th Jan 2008 10:08
Link
DGDK Loader for 3DWS

OK, I have the brushes up and running now. Screenshot available for download below. Just one slight problem, I can seem to get the shader to work in DarkGDK. It works fine in DBPro but when I apply the effect in DARKGDK my brushes mysteriously disappear!!! So currently I have no light mapping on the brushes.

The light maps are working fine and I can see those applied to the brushes and all looks just as it should. I turned the light map texturing off for the screen shot so the proper textures show through.

I think I'll have a look through the DarkGDK shader posts to see if Green Gandalf has a later version of the shader and see if that cures the problem. Otherwise ... its on to coding the meshes now

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 26th Jan 2008 11:02 Edited at: 26th Jan 2008 11:04
Link
Hey man, looking great. There was a version of DBP where the DBP would do that if the shader contained a version lower than 2.0 Try this attached shader.

[edit] Make sure your card can support version 2.0 pixel shader and make sure you set the effect tecnique to t0

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 26th Jan 2008 11:33
Link
Hey thanks LIT, that did the trick! Fully lightmapped now and you've saved me loads of time searching. Thanks again man.

I'd better get back to some coding then ... lol.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 26th Jan 2008 13:16
Link
PS2.0 = No good :<


Click For Details!
Back to top
Profile PM Email
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 26th Jan 2008 21:24
Link
Quote: "PS2.0 = No good :<"


I agree for that shader anyway. It runs way faster under 1.2 version, but if DBP/DGDK won't run 1.2 then 2.0 is better than nothing until Lee fixes DGDK.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 3rd Feb 2008 11:53 Edited at: 3rd Feb 2008 12:30
Link
DGDK Loader for 3DWS

Good news, the mesh loading is now complete. Example screenshot below.

That pretty much completes the coding I just need to do some exhaustive testing now, tidy the code up a bit and ensure there are no memory leaks.

Once that’s complete I'll make the code freely available so others can use and modify it as they feel fit.

I will be integrating it into my Game Engine, along with Dark Physics, with some specific enhancements concerning entities so I can pretty much control a lot of things from within the level design.

[EDIT]
Out of interest the loader currently takes 9 seconds to load and render my test level containing 516,168 polys.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
21
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 3rd Feb 2008 14:22
Link
Awesome man, glad to hear it. It looks like it is going to be a bit before I can get back to mine. I don't know quite how long just yet.

Back to top
Profile PM Email
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 4th Feb 2008 21:31 Edited at: 5th Feb 2008 00:53
Link
Thanks LIT. Hope your back coding again soon, guess you have other commitments again at the moment!

Out of interest, I have been loading a lot of different levels as part of my testing of the loader and it all seems to be going really well. However, I have noticed a couple of things which initially I am not able to explain and I wondered if you could shed any light on them.

As most of my levels don't contain many brushes, I thought I'd load Josh's 'Complex' level to see how it faired with that. Apart from the fact that I can't load his textures or meshes due to their file formats, it loaded the terrain and brushes no problem. But then I noticed the frame rate. I was only getting about 15 fps on average for what is nominally about 70000 polys! This contrasting with my levels where I am generally getting fps in excess of 70 for poly counts in excess of 250,000!

Surprise number 2 was the fps in DBPro for the same tests. Slightly higher frame rates for my levels, but over double the frame rate for the Complex test, averaging about 33 fps!

Do you have any idea why the really poor performance with lots of brushes, is it down to the number of objects created?

I've included a comparison screen shot below.

[EDIT]
Think I might have answered one of the questions. I think the some of the difference between the DBPro and DarkGDK frame rates might be down to the shader speed, DarkGDK having to run with PS 2.0. If I take the shader off in DarkGDK I get frame rates of 30+

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 6th Feb 2008 01:11
Link
Decided to convert all the textures for the Complex 3DWS level so I could see how well the new 3DWS loader copes. Seems to handle it quite well. Screenshots below:







No matter how good your code is, someone will improve on it
Back to top
Profile PM
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 6th Feb 2008 21:06
Link
hmmm ... it’s getting more interesting. I exported the complex level from 3DWS as a .dbo file and wrote a program to convert the embedded file extensions from .stf to .png to match my replacement textures. I then loaded this into my current DarkGDK game engine to see what sort of frame rates I could get. As the screenshot below shows, it's a huge improvement on the previous and this is with some extra overhead of ODE physics updates every frame.



It would appear that the .dbo approach of containing everything as limbs within a single object is possibly paying huge dividends here! My frame rate never dropped below 79 anywhere in the level. I'm just not sure if this is telling me that Dark Basic really struggles once the object counts get a bit high, or if it's still down to some other reason as yet unidentified.

May need to re-think how I construct the level within the 3DWS loader.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
jason p sage
18
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 7th Feb 2008 00:16
Link
@Pixel Perfect - First off - always love your work man!

Second- I have a few thoughts about Dark Basic Pro and DarkGDK when it comes to Object Counts etc...

First: Less Objects BETTER! If you can make limbs in One Object - and cull them correctly - this is better from the "Number of Objects" issue I believe exists.

Second: When Culling - EXCLUDING and Object is more efficient than HIDING a limb - (The counter argument to putting everything in an object with tons of limbs)

Conclusion? There is no best answer - but where it is logical to put a group of limbs into one object - and manage the limb culling yourself (Via Lost-In-Thoughts Limb FRUSTRUM culling) - Go for it - there are gains.

If you have a REALLY complex "MODEL" with a zillion verts... but can break it into ... say a reason number of complete objects... say 10 ro 20 objects versus making into limbs - then you can benefit from the ability to EXCLUDE OBJECT ON - which is WAY more performance enhancing then just hiding a limb of equal vertices.

Drawback? Well - my values I mentioned - 10 or 20 - is really arbitray (I made em up) and as they say here - your results will vary - but I found that if you are at least aware of these two main "strategies" you can at least TRY to make use of the strenghes and overcome certain game engine weaknesses by understanding them.

Why is hiding an object more efficient then hiding a limb? I read that EXCLUDE totally removes the object's mesh from the GFX pipelines 100%, where hiding a limb does prevent render but the mesh remains in video ram until excluded.

Why not make everything an object then? Because Performance drops exponentially as the numbers of objects increase. I've read this is due to internals in DarkBasic Pro and DarkGDK - how the "List of objects" is managed. ALSO the other IMPORTANT thing to keep in mind for ALL this DBP and GDK stuff is - loading/deleting/creating/deleting OBJECTS throughout your game will eventually lead to problems... say player plays for half hour - then things start to disappear - texture go away, objects don't show up ...etc.

@ PixelPerfect - I love how your loader is coming along. Will this be somethng you will be sharing with us when you finish? (I haven't read thread thoroughly - perhap I should but I want to go code now ) Because I would like to have a REAL 3dws level loaded into Iron Infantry - not a texturely flawed Direct.X export or something I figure the way you are doing it - I could have a building LOD just the outside - and pop in the 3dws level when a player enters the building etc... dunno - but the limb culling dbo thing sounds promising!


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 7th Feb 2008 20:51
Link
Hi Jason and thanks for your comments.

With regard to the DGDK Loader for 3DWS ... yes I will be making the code freely available once I've finished testing it and I'm happy it's working as well as it can with reasonable frame rates. People are then welcome to take it and modify it as they feel fit.

I read your remarks with interest and further testing has confirmed that object counts, once beyond a certain point, do start to degrade the frame rate quickly.

I also tried a simple experiment of testing for objects on screen in an object loop and excluding those that are not, however it revealed that the dbObjectInScreen function seems to be seriously flawed often reporting objects clearly well in screen as being off so that's not looking promising.

I think as you suggest a combination of limited numbers of objects containing many limbs is probably the way to go, although as we both know from our experiments in the past with .dbo exports, this technique can cause problems with correct alpha transparency rendition and control of individual limb transparency is currently not available in DGDK.

The idea of breaking the 3DWS Scene up into a limited number of objects may help with this as seperate transparency settings can be applied to each, this also fits in with my general idea of using parhaps object labelling or groups in 3DWS to control what goes into which objects allowing for a pseudo portal occlusion type culling system where objects belonging to groups outside of the current group the user is in are automatically excluded from the rendering process.

Currently the speed is definitely there with the low object high limb combination and as you say combined with Frustum Culling would maximise the frame rates. So maybe I will concentrate my efforts initially in this direction.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
jason p sage
18
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 7th Feb 2008 21:12
Link
I think Object in screen is hosed but I did stumble onto a SET OBJECT RADIUS command I think might effect how it works. I think it works like Sphere Frustrum Culling.

Note: Cube and Box are more accurate....

I haven't had time to look into this set object radius command - if its just manipluating the object then lame - but it might effect how object in screen works.


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 9th Feb 2008 10:51
Link
DGDK Loader for 3DWS Update

Well after some fairly extensive testing I think the following can safely be said:

The loader seems to cope with anything I throw at it including Josh's 'complex' level, constructing and rendering these levels without issue.

Unlike the DBO export from 3DWS it appears to render the levels pretty much as seen in 3DWS without the darkening and loss of color intensity that I tend to see when loading the DBO. Everything looks brighter and sharper.

When loading levels of high complexity (as shown by the 'complex' level) DGDK is really struggling to maintain decent frame rates. Typical Object and Limb counts being 2344 and 2802 respectively. Its running between 15 - 18 fps at 1024x769x32 full screen running on a Pentium4 3GHz, 2Gb RAM, Gainward 7800GS+ with 512Mb video RAM. This contrasts with the DBO export which runs between 76 - 82 fps. Having said that, most of my somewhat less populated levels are running at 80+ fps.

Having talked to LIT and got some advice on this I believe the main reason for this is a combination of factors including:

The DBO format uses quads which the game engine is able to use more efficiently reducing the vertex data by 33% straight off.

The DBO format allows the use of DBP's blend mode effect on a lower level (per limb texturing).

We have to use a separate and slightly slower shader for the same effect, as the blending command makes you specify the image numbers instead of using the images mapped to the object.

Possible other lower level advantages that I'm not even aware off that TGC deploy in preparing the data for rendering.

Out of interest, there has been a lot of talk and suggestion regarding the distribution of objects and limbs in order to optimise the frame rate. Having re-designed the code last night to allow a continuous variation between the number of objects generated and their limb counts I was unable to see any real improvement in frame rate anywhere between a single object containing everything else as limbs and every item as an object in its own right. It may be with lower levels of complexity this becomes more significant!

So currently, in order to try to get the performance increases in complex levels I'm looking at the following:

Introducing frustum culling to dramatically reduce the number of objects/limbs being rendered ... I'm looking at LITs code again and other methods I've sourced - thanks to Jason for your source code too! dbObjectInScreen is out of the window as although it appears to work really well with simple primitive type objects, it’s completely un-useable in typical complex game levels culling objects on screen as well as off.

At LITs suggestion, exploring vertex welding.

If anyone out there has any detailed knowledge regarding the internal processing of DBO files and what brings about the dramatic speed improvements I'd be really interested.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Pixel Perfect
18
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 11th Feb 2008 20:13
Link
Think I've found a 'leaner and meaner' algorithm for sphere based frustum culling than the ones I've seen in use so far, so I'm going to spend the next few days playing around with that.

I really don't want to hold back the release of the loader code if I can avoid it, it's just that the performance issues encountered so far with complex levels need addressing. Whatever solutions I find will probably have knock on effect on the current design of the loader.

Either way, I will not be incorporating frustum culling into the loader as this would be better integrated directly into individual game engines.

I'm hoping I can make some decisions by the weekend on this and then spend a week tidying up the code prior to release.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2025-08-08 11:14:24
Your offset time is: 2025-08-08 11:14:24