reckless@Posted: Wed Sep 05, 2012 8:18 am :

ok loads now and at first it looked ok but then i got "Surface Interactions not allocated" and things started to look really weird.

reckless@Posted: Wed Sep 05, 2012 9:25 am :

Getting there but still a few bumps to iron out it seems.

With the missing function implemented it loads without problems but light seems to have trouble updating causing some odd effects.

If you turn off your flashlight the world goes completely dark.
Light only affects things in front of the player everything else is dark with big blocky shadows.

besides that it seems to react a good deal faster so its definatly worth getting it fixed

jmarshall23@Posted: Thu May 10, 2012 10:56 am :

Hey,

I'm putting this in this forum cause not too many people check the doom 3 code section and that forum doesn't populate on the main page. While working on idTech 4 CDK my 12k weapon model mesh and 22k level was slowing shit down considerably. Well while tracing down a memory leak I found out that the Doom 3 renderer allocates and frees memory each frame for each number of meshes you have in your scene. After applying this fix I get a constant 10-15fps increase, in stock d3 you'll probably get more.

Open Interaction.cpp and find

Code:

//
// create slots for each of the model's surfaces
//
numSurfaces = model->NumSurfaces();

There is a r_staticalloc or something similar right below that line replace it with:

Code:

//
// create slots for each of the model's surfaces
//
numSurfaces = model->NumSurfaces();
surfaces = (surfaceInteraction_t *)model->GetSurfaceInteractions(); 
memset(&surfaces[0], 0, sizeof(surfaceInteraction_t) * model->NumSurfaces());

Find the freesurfaces function in the interaction.cpp and comment out R_StaticFree( this->surfaces );

In model.h in the "class idRenderModel" add

Code:

// Gets the surface interactions 
virtual const surfaceInteraction_t *GetSurfaceInteractions( void ) const = 0;

In model_local.h in the idRenderModelStatic class add

Code:

virtual const surfaceInteraction_t *GetSurfaceInteractions( void ) const;
idList<surfaceInteraction_t> interaction;

In model.cpp find the function

Code:

void idRenderModelStatic::AddSurface( modelSurface_t surface )

At the end of the function add:

Code:

// jmarshall
interaction.Alloc();
// jmarshall end

In Model_md5.cpp find the function idRenderModelMD5::InstantiateDynamicModel and find

Code:

// Remove Overlays before adding new surfaces
idRenderModelOverlay::RemoveOverlaySurfacesFromModel( staticModel );

Under that line add:

Code:

staticModel->interaction.Alloc();

Go back to model.cpp and in purgemodel function add

Code:

interaction.Clear();

Done.

Sikkpin@Posted: Thu May 10, 2012 2:24 pm :

Looks like "GetSurfaceInteractions()" needs to be defined.

Serpentine@Posted: Thu May 10, 2012 3:07 pm :

Pretty sure you'll get the same increase and drop some overhead if you just fix the InteractionTable (even just using a large fixed size like 4096*4096*sizeof(idInteraction)), or shifting it later in the load process to get a better number of lights/entities... or by making the resize function not destroy the table.

Might also want to enable r_useIndexBuffers, since that seems to help a little more.

VGames@Posted: Mon May 14, 2012 8:39 pm :

Would this help to render Sikkmod features such as Soft Shadows without bogging the game down?

VGames@Posted: Mon Jun 04, 2012 6:00 pm :

Is it worth doing this trick and what does it help do exactly?

nbohr1more@Posted: Tue Jun 05, 2012 5:30 am :

This trick reduces CPU overhead and RAM waste (not video RAM). Yes, since Sikkmod's current soft-shadow method requires redrawing the scene it should speed that up a bit on CPU limited systems. On GPU limited systems it may not have much effect.

Gir@Posted: Tue Jun 05, 2012 6:46 am :

I downloaded the GPL to add this Fix.

i downloaded Visual Studios 11, Direct X SDK, but i get this compile error. ?

Code:

1>  ChoiceWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  DeviceContext.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  EditWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  FieldWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  GameBearShootWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  GameBustOutWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  GameSSDWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  GuiScript.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  ListGUI.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  ListWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  MarkerWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  RegExp.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  RenderWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  SimpleWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  SliderWindow.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  UserInterface.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  Window.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  Generating Code...
1>  Compiling...
1>  Winvar.cpp
1>c:\users\miles\desktop\doom iii\ttimo-doom3.gpl-8047099\neo\idlib\../tools/comafx/StdAfx.h(38): fatal error C1083: Cannot open include file: 'afxwin.h': No such file or directory
1>  Generating Code...
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:09.05
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

jmarshall23@Posted: Tue Jun 05, 2012 6:55 am :

I haven't tried tried compiling with VS 2011, those errors means the compiler isn't loading in the MFC headers(i.e. the tools).

Quote:

Is it worth doing this trick and what does it help do exactly?

This is a CPU only time savior, and actually after applying this fix you will see a minor ram usage increase. Were this fix really comes in handy is if you are using assets that have a med/high vertex count. Even the old stock d3 assets will also render fast(er) after applying this fix, allocating/freeing that much memory is very CPU intensive and also creates fragmentation in aval memory.

Gir@Posted: Tue Jun 05, 2012 7:39 am :

I can't compile, someone release a binary with fix

Gzegzolka@Posted: Tue Jun 05, 2012 7:39 am :

Shouldn't this topic be in Doom3 source code forum folder? Those stuff can be done in cpp files while D3 vanilla got different stuff in pk4.

jmarshall23@Posted: Tue Jun 05, 2012 7:41 am :

Quote:

Shouldn't this topic be in Doom3 source code forum folder? Those stuff can be done in cpp files while D3 vanilla got different stuff in pk4.

I think your referring to either the script stuff or the game dll which would both be incorrect. It should be probably but I posted it here for more exposure becuase not really many people check that forum and the google crawler doesn't crawl that forum.

Quote:

I can't compile, someone release a binary with fix

Download VS2010 trial apply the fix and recompile.

Gir@Posted: Tue Jun 05, 2012 9:14 am :

I downloaded VS2010 Pro, and i get this error

Code:

1>sound\snd_system.cpp(167): error C2664: 'ALenum (ALubyte *)' : cannot convert parameter 1 from 'const char [16]' to 'ALubyte *'
1>          Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>sound\snd_system.cpp(167): error C2664: 'ALenum (ALubyte *)' : cannot convert parameter 1 from 'const char [16]' to 'ALubyte *'
1>          Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:03.56
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Gir@Posted: Tue Jun 05, 2012 9:16 am :

I fixed by doing this

Code:

//#if ID_OPENAL
//   common->Printf( "%8d kB total OpenAL audio memory used\n", ( alGetInteger( alGetEnumValue( "AL_EAX_RAM_SIZE" ) ) - alGetInteger( alGetEnumValue( "AL_EAX_RAM_FREE" ) ) ) >> 10 );
//#endif

I got an EXE

Gir@Posted: Tue Jun 05, 2012 10:04 am :

Just a quick off topic question

I noticed there's "Model_md3.h" in Doom 3, can Md3 models be loaded into Doom 3 since the code is there, i tried using "test_model" in console to load an MD3 but nothing shows up.

::edit::

I added this, md3 works @ CmdSystem

[ ".md3"]

Code:

ID_INLINE void idCmdSystem::ArgCompletion_ModelName( const idCmdArgs &args, void(*callback)( const char *s ) ) {
   cmdSystem->ArgCompletion_FolderExtension( args, callback, "models/", false, ".lwo", ".ase", ".md5mesh",".md3", ".ma", NULL );
}

Tron@Posted: Tue Jun 05, 2012 1:24 pm :

How about a nice timedemo comparison?

Gzegzolka@Posted: Tue Jun 05, 2012 1:41 pm :

jmarshall23 wrote:

Quote:

Shouldn't this topic be in Doom3 source code forum folder? Those stuff can be done in cpp files while D3 vanilla got different stuff in pk4.

OK, and is there way to actually put that in D3 vanilla?

jmarshall23@Posted: Tue Jun 05, 2012 3:01 pm :

Quote:

OK, and is there way to actually put that in D3 vanilla?

This works in d3 vanilla you just need to recompile the d3 exe from the gpl code base.

Serpentine@Posted: Tue Jun 05, 2012 3:55 pm :

You get a nice little bump in performance from the VS 11 / VS 2012 RC compiler, only 2-3 fps, and no XP bins... but hey.

The VS 2012 RC is also a whole lot more usable than the 11 beta too.

simulation@Posted: Tue Jun 05, 2012 5:08 pm :

Serpentine wrote:

You get a nice little bump in performance from the VS 11 / VS 2012 RC compiler, only 2-3 fps, and no XP bins... but hey.

The VS 2012 RC is also a whole lot more usable than the 11 beta too.

VS2012 will support XP as a target as a post-RTM patch. I'll be keeping away from VS2012 due to the .NET 4.5 release being an in-place upgrade. Wouldn't be so bad but 4.5 will not be on XP or Server 2K3, so that rules it out for many enterprise developers like me.

motorsep@Posted: Thu Jul 05, 2012 7:57 pm :

Gir wrote:

[ ".md3"]

Code:

ID_INLINE void idCmdSystem::ArgCompletion_ModelName( const idCmdArgs &args, void(*callback)( const char *s ) ) {
   cmdSystem->ArgCompletion_FolderExtension( args, callback, "models/", false, ".lwo", ".ase", ".md5mesh",".md3", ".ma", NULL );
}

Will animated md3 model work with this patch ?

Tom Yum 72@Posted: Fri Jul 06, 2012 11:03 am :

@ jmarshall23 and everybody else :

would you or someone else here be so kind and post a ready to go patch here, because i have absolutely no clue how to to this.
Big thanks !

motorsep@Posted: Sat Aug 04, 2012 11:20 pm :

Ok, trying to get it working and keep on getting error:

/home/user/neo/renderer/Model.h:318:16: error: ‘surfaceInteraction_t’ does not name a type

That's the line where it errors out

Code:

virtual const surfaceInteraction_t *GetSurfaceInteractions( void ) const = 0;

in class idRenderModel

Any ideas? Thanks.

VGames@Posted: Wed Aug 08, 2012 11:56 pm :

Did anybody ever get this working?

motorsep@Posted: Thu Aug 09, 2012 12:27 am :

nope

reckless@Posted: Thu Aug 09, 2012 2:57 am :

Sadly no it seems to be missing parts.
I tried recreating the missing bits but im no C++ guru so i ended up with something that compiled but it crashed when executed.

VGames@Posted: Thu Aug 09, 2012 6:53 pm :

That sucks. Oh well thanks for trying. I didn't even do that.

AnthonyJa@Posted: Fri Aug 10, 2012 1:05 pm :

I've not actually got as far as running d3 with this change (don't even have d3 on this PC), much less profiled it to see if it actually has any noticable effect. However.... I do have something that I believe should have everything needed to compile it.

Reckless - your use of "return 0" in GetSurfaceInteractions was a little, uh, reckless, and is the reason for your crash. What I believe you were looking for was "return interaction.Ptr()".

The patch is relative to my local set of code but hopefully can be applied to other codebases without too much trouble.

VGames@Posted: Fri Aug 10, 2012 8:34 pm :

Anybody use this yet?

motorsep@Posted: Fri Aug 10, 2012 8:38 pm :

I am about to attempt it

VGames@Posted: Fri Aug 10, 2012 9:42 pm :

Try using Sikkmod's soft shadow feature.

motorsep@Posted: Fri Aug 10, 2012 9:49 pm :

I am not after soft shadows, so I won't be trying it

motorsep@Posted: Fri Aug 10, 2012 10:03 pm :

AnthonyJa wrote:

Had to comment out shadowGen = SG_STATIC; in the Interaction.cpp to get it to compile. Besides that the engine compiles.

Well, the patch crashes Doom 3 (dhewm3 engine) when I start new game, and if I load testmaps/test_vehicle2 I see this: http://i.imgur.com/YZ8vm.jpg

Maybe it has something to do with shadowGen = SG_STATIC; but the patch wouldn't compile with that line.

AnthonyJa@Posted: Fri Aug 10, 2012 11:20 pm :

Odd, the patch shouldn't contain any change to a line like that...

Compare the patch to the first post and you should find that the only real differences are:
- GetSurfaceInteractions is implemented (as returning the newly added interactions variable)
- added an AllocInteraction method instead of requiring that interaction is a public variable
- changed the type definition of the surfaceInteraction_t struct and pre-declared it so that it could be used on the public interface

One thing worth checking (I cannot right now as cannot open my .zip from iPhone / iPad!) is that I remembered to disable the line Justin mentioned to comment out. Think I did but not certain as that was the bit that made me add an ifdef around it all and I may have forgotten to go back and do that one.

Try applying it to an engine that has less renderer changes, this change could conflict with other changes already in that fork.

Or just debug into the crash - surely if you are making a commercial game you have
A developer who knows how to use a debugger?

motorsep@Posted: Fri Aug 10, 2012 11:28 pm :

dhewm3 doesn't have any render changes. It still runs ARB2 path. The only thing we changed was adding depth buffer access, which should not interfere in any way with this patch.

Although I am not a programmer, I know how to use gdb debugger

Will l look into it in a bit.

Note that I didn't see any fps increase on the test_vehicle2 map.

AnthonyJa@Posted: Fri Aug 10, 2012 11:42 pm :

The first thing to do is definitely to compare the changes against my list above and the original post. The line you are saying needs to be commented out should be completely unaffected.

Probably automatically applying the patch has gone wrong because your codebase is different to mine, probably because of changes in interaction.cpp made on the dhewm3 fork (by renderer I was referring to the module within the code, which both this patch and dhewm3 have changed)

Can't say I have tried test_vehicle2 but I guess it is just a big box and so probably would t benefit from this change anyway. Try high poly count maps and models

motorsep@Posted: Sat Aug 11, 2012 12:55 am :

Ok, I re-enabled shadowGen = SG_STATIC; and commented out R_StaticFree( this->surfaces ); per jmarshall23 (which doesn't affect anything btw). And here we go:

/home/motorsep/games/steelstorm2_engine/neo/renderer/Interaction.cpp: In member function ‘void idInteraction::FreeSurfaces()’:
/home/motorsep/games/steelstorm2_engine/neo/renderer/Interaction.cpp:551:2: error: ‘shadowGen’ was not declared in this scope
make[2]: *** [CMakeFiles/SteelStorm2.dir/renderer/Interaction.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/SteelStorm2.dir/all] Error 2
make: *** [all] Error 2

reckless@Posted: Sat Aug 11, 2012 6:01 am :

Thanks gonna try it

only reason i had a return 0; in there was because i was not sure what to return still learning C++

reckless@Posted: Sat Aug 11, 2012 7:31 am :

Ok applied and better but still crashing even on unmodified doom3.
Crashes in memset(&surfaces[0], 0, sizeof(surfaceInteraction_t) * model->NumSurfaces()); with a NULL pointer to surfaces.
I can get it far enough to load a map but as soon as it finishes loading it will bail out with the above.

motorsep@Posted: Sat Aug 11, 2012 7:51 am :

I bet I am having the same issue as reckless, but I can't compile with shadowGen = SG_STATIC;

Care you elaborate why is it happening to me?

reckless@Posted: Sat Aug 11, 2012 1:41 pm :

Might need to check by hand if the patch applied cleanly.
Check for missing ; at the end of function variables like this->somefunction;
Can also be caused by misplaced defines like #define something without an #endif

AnthonyJa@Posted: Sat Aug 11, 2012 2:15 pm :

reckless wrote:

Hm shouldn't be null as it is being returned as interaction.ptr. Perhaps check with the debugger whether that list is empty, and what the value of NumSurfaces is (should presumably be equal go thr list length).

Also make sure you did the "comment out this line" as it sounds like I missed that out. That probably wouldn't cause it to be null but would cause it to be using a stale pointer which could av

motorsep@Posted: Sat Aug 11, 2012 5:44 pm :

I checked and rechecked

I also applied patch manually, line by line.

reckless@Posted: Sat Aug 11, 2012 6:19 pm :

Aye did comment the mentioned line out but to no avail :/

i get an awfull heap of pointers with the value ??? from the debugger.
But it cannot point me to the direct cause why.
I had the same problem many times when working on Quake1 and the debugger is correct it is a bad pointer somewhere but the msvc debugger had some trouble telling me where so i had to sift through the entire codebase to find the cullprit. Turned out to be an old bug in the quake1 code which manifested itself with some of my modifications :S.

reckless@Posted: Tue Aug 14, 2012 3:02 pm :

Lots of debugging later ... its an allocation error.
Looks like interaction.Alloc(); is sometimes throwing a NULL pointer my best guess is that theres still something missing.
I can get it to work by using the old staticalloc but that kinda breaks the purpose :S.

So needs more bugtesting im afraid.

VGames@Posted: Tue Aug 14, 2012 3:52 pm :

Keep us updated. Can we expect an increase in FPS while using Sikkmod features like Soft Shadows?

reckless@Posted: Tue Aug 14, 2012 8:07 pm :

Not sure tbh. Ive not delved to deeply into how sikks soft shadows work but everything that amounts to a speedup will help in the long run

AnthonyJa@Posted: Thu Aug 23, 2012 1:36 am :

reckless wrote:

Looks like Justin had probably already removed some other places that add surfaces that aren't using AddSurface (that line has an implicit assumption that surfaces.Count <= interaction.Count). You need additional blocks of code like this (when using my version of the patch, otherwise use "staticModel->interaction.Alloc()"):

#ifdef USE_JUSTINS_SURFACES_OPT
staticModel->AllocInteraction();
#endif

They need to go into anywhere that is doing surfaces.Alloc() - which appears to be idRenderModelPrt::InstantiateDynamicModel and idRenderModelOverlay::AddOverlaySurfacesToModel().

Having done this, it doesn't crash for me (on one test map, so not lots of testing), however I'm not seeing a big speedup for me. Probably not bottlenecking there on this PC as it has other issues...

reckless@Posted: Thu Aug 23, 2012 3:03 am :

Hmm sounds plausible <Mythbuster voice>

Ill take some test runs

reckless@Posted: Thu Aug 23, 2012 4:19 am :

Hmm ouch :S while the first version crashed on map load this one crashes instantly.

Mh at inside3d had some thoughts about speeding the engine up seriously but its a big undertakement that will require most of the vertex cache to be rewritten.

AnthonyJa@Posted: Thu Aug 23, 2012 7:31 am :

It really shouldn't be any worse than the last one, since it is exactly the same except for some more cases are handled where the interaction list is too small. Inspect the size of it and compare it to the number of surfaces, and also check the type of model.

Temporarily make surfaces private to see if you have any other examples where something does surfaces.Alloc which doesn't now Alloc an interaction (that is how I found those two new ones)

reckless@Posted: Thu Aug 23, 2012 8:42 am :

Aye checked the occurances and found only the two you listed but something is still amiss :/
Im putting it on the backburner for now while i work on integrating xreals renderer in doom3.

motorsep@Posted: Mon Aug 27, 2012 12:54 am :

Finally tested MD3 models in Doom 3. Models can be loaded, but can not be used with idAnimated. A code needs to be written to trigger and play animated MD3 files using idAnimated.

reckless@Posted: Tue Sep 04, 2012 11:20 am :

Noticed jmarshall was back so maybe he can fill in on what may be wrong ?.

Btw i posted some optimized VBO code in the code section it has been tested on both ATI and Nvidia and provides a nice speedup.

The version i posted are for engines that have the old backend functions removed but should be easy to revert the missing functions for virtualmem (Yuck).

Its also been ported for dhewm3

jmarshall23@Posted: Wed Sep 05, 2012 6:46 am :

Can you guys quickly rehash what problems you guys are having?

reckless@Posted: Wed Sep 05, 2012 7:31 am :

We had a few cases of missing function pointers (most got found out so now it compiles) but it crashes with a null pointer error so we been stuck ever since

jmarshall23@Posted: Wed Sep 05, 2012 7:36 am :

Where are you guys getting the null pointer issue?

reckless@Posted: Wed Sep 05, 2012 7:40 am :

this part ->

//
// create slots for each of the model's surfaces
//
numSurfaces = model->NumSurfaces();
surfaces = (surfaceInteraction_t *)model->GetSurfaceInteractions(); // explodes here with null pointer error
memset(&surfaces[0], 0, sizeof(surfaceInteraction_t) * model->NumSurfaces());

the weird thing is that it should work with the patches posted but somethings amiss.

jmarshall23@Posted: Wed Sep 05, 2012 7:46 am :

Opps I forgot to define GetSurfaceInteractions, sorry about that:

Code:

/*
================
idRenderModelStatic::GetSurfaceInteractions
================
*/
const surfaceInteraction_t *idRenderModelStatic::GetSurfaceInteractions( void )  const {
   // I'm spitting out a warning here cause this shouldn't happen(but it is).
   if(interaction.Num() <= 0) {
      common->Warning("Surface Interactions not allocated - creating %d\n", NumSurfaces() );
      for(int i = 0; i < NumSurfaces(); i++)
      {
         ((idRenderModelStatic *)this)->interaction.Alloc();
      }
   }
   return &interaction[0];
}

Try that and see if it works.

reckless@Posted: Wed Sep 05, 2012 7:48 am :

These are the two missing functions AnthonJa found.

/*
================
idRenderModelStatic::GetSurfaceInteractions
================
*/
const surfaceInteraction_s *idRenderModelStatic::GetSurfaceInteractions( void ) const
{
return interaction.Ptr();
}

/*
================
idRenderModelStatic::AllocInteraction
================
*/
void idRenderModelStatic::AllocInteraction( void )
{
interaction.Alloc();
}

GetSurfaceInteractions returns the ptr to the interaction table but for some odd reason it also passes empty data as a null pointer and msvc is all but happy about it doing that :S

reckless@Posted: Wed Sep 05, 2012 7:49 am :

yay ok lets try again hope it works this time.

reckless@Posted: Wed Sep 05, 2012 8:18 am :

ok loads now and at first it looked ok but then i got "Surface Interactions not allocated" and things started to look really weird.

reckless@Posted: Wed Sep 05, 2012 9:25 am :