--
[ Picked text/plain from multipart/alternative ]
Check out cl_dll/detailobjectsystem.cpp. Detail models are stored in their
own lump in the bsp and are loaded in the client dll by CDetailObjectSystem
at CDetailObjectSystem::LevelInitPreEntity
Notice the LoadGameLump call from the engine interface to load
GAMELUMP_DETAIL_PROPS from the bsp. Then it deserializes the data in the
lump and a bunch of initializes CDetailModel classes which are the
IClientRenderables that render the details. So, the CDetailModels do their
rendering in DrawModel.
If you check out CDetailModel::DrawModel you will see that it actually
renders itself like this:
int drawn = modelrender->DrawModel(
flags,
this,
MODEL_INSTANCE_INVALID,
-1, // no entity index
m_pModel,
m_Origin,
m_Angles,
0, // skin
0, // body
0 // hitboxset
);
Notice the hard-coded 0 for the skin parameter. If you want detail models to
support multiple skins you will have to modify vbsp to pack the skin index
into the detial lump, then modify CDetailObjectSystem::UnserializeModels to
unpack the skin index and then CDetailModel would need to store off the skin
index and pass this index to modelrender->DrawModel.
Regards,
Paul
On 10/23/06, Andrew Forsberg <[EMAIL PROTECTED]> wrote:
>
> Hi guys,
>
> One of the mappers on a hl2 mod I'm helping code has asked if I can
> enable multiple skins for prop_detail. He added this to the fgd file:
>
> @BaseClass = prop_detail_base
> [
> model(studio) : "World model"
> skin(integer) : "Skin" : 0
> ]
>
> And then is using different ints to identify, say, 10 different skins
> for the same grass (or shrub, or...) model.
>
> So far so good, but once compiled it all falls back to the default skin
> (0) in game. He knows about using detail_group, but doesn't want the
> skins to be random, he wants them to be specifiable in hammer.
>
> I'm not completely new to the SDK, but I'm also not very familiar with
> it. I've searched it for occurrences of prop_detail, but as far as I can
> see the only place it appears is in vbsp/detailobjects.cpp. Messing with
> that doesn't seem like a good idea.
>
> Can someone point me in the right direction? Or is this an issue that
> needs to be enabled at the engine/closed source side of things?
>
> If it's relevant, our main development trunk is currently using the SDK
> without the recent updates from Valve.
>
> Cheers & thanks,
> Anders
>
>
>
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
