Re: [hlcoders] SteamWorks we should get a piece of that pie ;)

[Cory de La Torre]

--
[ Picked text/plain from multipart/alternative ]
Lol.

On Jan 30, 2008 12:05 AM, Rodrigo 'r2d2rigo' Diaz <[EMAIL PROTECTED]>
wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> http://collective.valve-erc.com/index.php?news=1080357489-51167900
>
> Hey, it says "in a few weeks", so according to Valve time we will get it
> along with Episode 3 :P
>
> 2008/1/30, Maarten De Meyer <[EMAIL PROTECTED]>:
> >
> > Reason is simple I think. Steam is a success already with some big
> > publishers using it. Valve does not need mods anymore to promote its
> > platform, on the contrary, we would only be in competition with the real
> > 'paying' Valve clients and even be bad PR by offering lesser quality
> > products than the current Steam offer.
> >
> > Plus if they would want to support even only the 'better' mods out
> there,
> > they'd still end up with a list of a few dozen mods, for which they'd
> have
> > to do the distribution etc, logistically this is very expensive. Not to
> > mention quality control, it'd be a nightmare.
> >
> > Actually - and please don't read a reproach in this valve, from a
> business
> > point of view, they have no interest at all in supporting mods. If Steam
> > would not have become a success of its own, mods could have been
> > interesting to boost the platform, but now, they would be stupid to
> > support us logistically.
> >
> > So in my eyes they're doing what they can within their business
> > constraints. They provide us with an extensive SDK, a mailing list +
> > personal email support, and Mike Durand's extra hours. They let us do
> the
> > distribution/versioning etc so that they don't offend their paying steam
> > publisher clients, but allow us to still use the platform.
> >
> > I don't think we can ask for more really. Except maybe that yeah, they
> > shouldn't have made that promise earlier on [ if they really did, my
> > memory is already becoming vague on the subject :p ]
> >
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Remember that Valve promised Steam Delivery for Mods a long, long time
> > > ago,
> > > and for whatever reason, that never came to fruition. Don't hold your
> > > breath
> > > for anythin like this
> > >
> > > On Jan 30, 2008 11:31 AM, Tom Leighton <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > >> Could VALVe not implement an api where that a mod "ID" if you will is
> > >> registered with SteamWorks, (no need for anything fancy, maybe a guid
> > >> style id, or simply a number), and then the mod developers can add
> > >>
> > >> Update URL (Update location, maybe some data files to tell what
> update
> > >> is newer, etc)
> > >> Stats URL (Stats location, used for achievements, etc)
> > >>
> > >> and stuff like that. It means valve dont store anything, we can have
> > >> steam functionality, and maybe even an integrated steam
> > >> download/installer? :P
> > >>
> > >> >> Not at this time, we don't have a pipeline in place to support
> > >> arbitrary
> > >> >> mods let alone the infrastructure for it :)
> > >> >>
> > >> >> - Alfred
> > >> >>
> > >> >>
> > >> >>> -Original Message-
> > >> >>> From: [EMAIL PROTECTED] [mailto:hlcoders-
> > >> >>> [EMAIL PROTECTED] On Behalf Of Adam Buckland
> > >> >>> Sent: Tuesday, January 29, 2008 2:27 PM
> > >> >>> To: hlcoders@list.valvesoftware.com
> > >> >>> Subject: Re: [hlcoders] SteamWorks we should get a piece of that
> > pie
> > >> >>>
> > >> >> ;)
> > >> >>
> > >> >>> Actually, on another note, there's the achievement manager code
> in
> > >> the
> > >> >>> SDK code. Does this mean that mod authors will be able to
> > >> incorporate
> > >> >>> achievements in their mods?
> > >> >>>
> > >> >>>
> > >> >>> On 29 Jan 2008, at 22:21, Benjamin Davison wrote:
> > >> >>>
> > >> >>>
> > >>  --
> > >>  [ Picked text/plain from multipart/alternative ]
> > >>  http://www.steampowered.com/steamworks/
> > >> 
> > >>  Are mod authors ever going to be able to get in on this action?
> > >> Some
> > >>  of the
> > >>  features look mighty tasty.
> > >> 
> > >>  --
> > >>  - Benjamin Davison
> > >>  --
> > >> 
> > >>  ___
> > >>  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
> > >> >>>
> > >> >> ___
> > >> >> To unsubscribe, edit your list preferences, or view the list
> > >> archives,
> > >> >> please visit:
> > >> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > Matt Stafford (Wraiyth)
> >

Re: [hlcoders] SteamWorks we should get a piece of that pie ;)

[Rodrigo 'r2d2rigo' Diaz]

--
[ Picked text/plain from multipart/alternative ]
http://collective.valve-erc.com/index.php?news=1080357489-51167900

Hey, it says "in a few weeks", so according to Valve time we will get it
along with Episode 3 :P

2008/1/30, Maarten De Meyer <[EMAIL PROTECTED]>:
>
> Reason is simple I think. Steam is a success already with some big
> publishers using it. Valve does not need mods anymore to promote its
> platform, on the contrary, we would only be in competition with the real
> 'paying' Valve clients and even be bad PR by offering lesser quality
> products than the current Steam offer.
>
> Plus if they would want to support even only the 'better' mods out there,
> they'd still end up with a list of a few dozen mods, for which they'd have
> to do the distribution etc, logistically this is very expensive. Not to
> mention quality control, it'd be a nightmare.
>
> Actually - and please don't read a reproach in this valve, from a business
> point of view, they have no interest at all in supporting mods. If Steam
> would not have become a success of its own, mods could have been
> interesting to boost the platform, but now, they would be stupid to
> support us logistically.
>
> So in my eyes they're doing what they can within their business
> constraints. They provide us with an extensive SDK, a mailing list +
> personal email support, and Mike Durand's extra hours. They let us do the
> distribution/versioning etc so that they don't offend their paying steam
> publisher clients, but allow us to still use the platform.
>
> I don't think we can ask for more really. Except maybe that yeah, they
> shouldn't have made that promise earlier on [ if they really did, my
> memory is already becoming vague on the subject :p ]
>
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Remember that Valve promised Steam Delivery for Mods a long, long time
> > ago,
> > and for whatever reason, that never came to fruition. Don't hold your
> > breath
> > for anythin like this
> >
> > On Jan 30, 2008 11:31 AM, Tom Leighton <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Could VALVe not implement an api where that a mod "ID" if you will is
> >> registered with SteamWorks, (no need for anything fancy, maybe a guid
> >> style id, or simply a number), and then the mod developers can add
> >>
> >> Update URL (Update location, maybe some data files to tell what update
> >> is newer, etc)
> >> Stats URL (Stats location, used for achievements, etc)
> >>
> >> and stuff like that. It means valve dont store anything, we can have
> >> steam functionality, and maybe even an integrated steam
> >> download/installer? :P
> >>
> >> >> Not at this time, we don't have a pipeline in place to support
> >> arbitrary
> >> >> mods let alone the infrastructure for it :)
> >> >>
> >> >> - Alfred
> >> >>
> >> >>
> >> >>> -Original Message-
> >> >>> From: [EMAIL PROTECTED] [mailto:hlcoders-
> >> >>> [EMAIL PROTECTED] On Behalf Of Adam Buckland
> >> >>> Sent: Tuesday, January 29, 2008 2:27 PM
> >> >>> To: hlcoders@list.valvesoftware.com
> >> >>> Subject: Re: [hlcoders] SteamWorks we should get a piece of that
> pie
> >> >>>
> >> >> ;)
> >> >>
> >> >>> Actually, on another note, there's the achievement manager code in
> >> the
> >> >>> SDK code. Does this mean that mod authors will be able to
> >> incorporate
> >> >>> achievements in their mods?
> >> >>>
> >> >>>
> >> >>> On 29 Jan 2008, at 22:21, Benjamin Davison wrote:
> >> >>>
> >> >>>
> >>  --
> >>  [ Picked text/plain from multipart/alternative ]
> >>  http://www.steampowered.com/steamworks/
> >> 
> >>  Are mod authors ever going to be able to get in on this action?
> >> Some
> >>  of the
> >>  features look mighty tasty.
> >> 
> >>  --
> >>  - Benjamin Davison
> >>  --
> >> 
> >>  ___
> >>  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
> >> >>>
> >> >> ___
> >> >> To unsubscribe, edit your list preferences, or view the list
> >> archives,
> >> >> please visit:
> >> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Matt Stafford (Wraiyth)
> >> > http://www.wraiyth.com
> >> > --
> >> >
> >> > ___
> >> > 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, 

Re: [hlcoders] SteamWorks we should get a piece of that pie ;)

[Maarten De Meyer]

Reason is simple I think. Steam is a success already with some big
publishers using it. Valve does not need mods anymore to promote its
platform, on the contrary, we would only be in competition with the real
'paying' Valve clients and even be bad PR by offering lesser quality
products than the current Steam offer.

Plus if they would want to support even only the 'better' mods out there,
they'd still end up with a list of a few dozen mods, for which they'd have
to do the distribution etc, logistically this is very expensive. Not to
mention quality control, it'd be a nightmare.

Actually - and please don't read a reproach in this valve, from a business
point of view, they have no interest at all in supporting mods. If Steam
would not have become a success of its own, mods could have been
interesting to boost the platform, but now, they would be stupid to
support us logistically.

So in my eyes they're doing what they can within their business
constraints. They provide us with an extensive SDK, a mailing list +
personal email support, and Mike Durand's extra hours. They let us do the
distribution/versioning etc so that they don't offend their paying steam
publisher clients, but allow us to still use the platform.

I don't think we can ask for more really. Except maybe that yeah, they
shouldn't have made that promise earlier on [ if they really did, my
memory is already becoming vague on the subject :p ]


> --
> [ Picked text/plain from multipart/alternative ]
> Remember that Valve promised Steam Delivery for Mods a long, long time
> ago,
> and for whatever reason, that never came to fruition. Don't hold your
> breath
> for anythin like this
>
> On Jan 30, 2008 11:31 AM, Tom Leighton <[EMAIL PROTECTED]>
> wrote:
>
>> Could VALVe not implement an api where that a mod "ID" if you will is
>> registered with SteamWorks, (no need for anything fancy, maybe a guid
>> style id, or simply a number), and then the mod developers can add
>>
>> Update URL (Update location, maybe some data files to tell what update
>> is newer, etc)
>> Stats URL (Stats location, used for achievements, etc)
>>
>> and stuff like that. It means valve dont store anything, we can have
>> steam functionality, and maybe even an integrated steam
>> download/installer? :P
>>
>> >> Not at this time, we don't have a pipeline in place to support
>> arbitrary
>> >> mods let alone the infrastructure for it :)
>> >>
>> >> - Alfred
>> >>
>> >>
>> >>> -Original Message-
>> >>> From: [EMAIL PROTECTED] [mailto:hlcoders-
>> >>> [EMAIL PROTECTED] On Behalf Of Adam Buckland
>> >>> Sent: Tuesday, January 29, 2008 2:27 PM
>> >>> To: hlcoders@list.valvesoftware.com
>> >>> Subject: Re: [hlcoders] SteamWorks we should get a piece of that pie
>> >>>
>> >> ;)
>> >>
>> >>> Actually, on another note, there's the achievement manager code in
>> the
>> >>> SDK code. Does this mean that mod authors will be able to
>> incorporate
>> >>> achievements in their mods?
>> >>>
>> >>>
>> >>> On 29 Jan 2008, at 22:21, Benjamin Davison wrote:
>> >>>
>> >>>
>>  --
>>  [ Picked text/plain from multipart/alternative ]
>>  http://www.steampowered.com/steamworks/
>> 
>>  Are mod authors ever going to be able to get in on this action?
>> Some
>>  of the
>>  features look mighty tasty.
>> 
>>  --
>>  - Benjamin Davison
>>  --
>> 
>>  ___
>>  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
>> >>>
>> >> ___
>> >> To unsubscribe, edit your list preferences, or view the list
>> archives,
>> >> please visit:
>> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Matt Stafford (Wraiyth)
>> > http://www.wraiyth.com
>> > --
>> >
>> > ___
>> > 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
>>
>>
>
>
> --
> Matt Stafford (Wraiyth)
> http://www.wraiyth.com
> --
>
> ___
> 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://

[hlcoders] Achievements

[Matt Stafford]

--
[ Picked text/plain from multipart/alternative ]
This is mainly directed to Mike (or anyone from Valve)
Is it possible for us to use the existing Achievements code to create our
own ones for mods, and upload that data to our own server? I'm not sure
where the Achievements game menu panel gets the list from, but I've tried
heaps and nothing will list there (hazarding a guess its probably something
in the Steam API). Is the code only there because trying to remove something
integrated into the codebase that much would be hell, or is it actually
useful to us?

Cheers
Matt

--
Matt Stafford (Wraiyth)
http://www.wraiyth.com
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Panels not playing nice.

[Mark Chandler]

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Hey guys got this problem that shouldn't be atm.

Ok I made a new vgui class based from the vgui::panel class:
class PD_BasePanel : public vgui::Panel

now in that class I have overwritten the OnMousePressed and
OnMouseDoublePressed functions:

void OnMousePressed(MouseCode code)
{
if (code == MOUSE_LEFT)
{
PostActionSignal(new KeyValues("ItemClick","name",
this->GetName()));
}
}
void OnMouseDoublePressed(MouseCode code)
{
Msg("XXX Code is: %d \n", code);
if (code == MOUSE_LEFT)
{
PostActionSignal(new
KeyValues("ItemDoubleClick","name", this->GetName()));
}
}

However the OnMousePressed function works like a charm but
OnMouseDoublePressed doesn't work at all. So I went and put a msg into the
panel.cpp OnMouseDoublePressed function:

void Panel::OnMouseDoublePressed(MouseCode code)
{
Msg("Mouse Doubled Pressed Base class \n");
}

And this works but it is not been overwritten by my class. Any suggestions
as Im lost to why its not been overwritten.

Lodle

--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] Panels not playing nice.

[Mark Chandler]

Same result

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Maras
(memzero)
Sent: Wednesday, January 30, 2008 10:38 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Panels not playing nice.

Try making them virtual functions.

//   Adam Maras (memzero)

Mark Chandler wrote:
> This is a multipart message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hey guys got this problem that shouldn't be atm.
>
> Ok I made a new vgui class based from the vgui::panel class:
>   class PD_BasePanel : public vgui::Panel
>
> now in that class I have overwritten the OnMousePressed and
> OnMouseDoublePressed functions:
>
>   void OnMousePressed(MouseCode code)
>   {
>   if (code == MOUSE_LEFT)
>   {
>   PostActionSignal(new KeyValues("ItemClick","name",
> this->GetName()));
>   }
>   }
>   void OnMouseDoublePressed(MouseCode code)
>   {
>   Msg("XXX Code is: %d \n", code);
>   if (code == MOUSE_LEFT)
>   {
>   PostActionSignal(new
> KeyValues("ItemDoubleClick","name", this->GetName()));
>   }
>   }
>
> However the OnMousePressed function works like a charm but
> OnMouseDoublePressed doesn't work at all. So I went and put a msg into the
> panel.cpp OnMouseDoublePressed function:
>
> void Panel::OnMouseDoublePressed(MouseCode code)
> {
>   Msg("Mouse Doubled Pressed Base class \n");
> }
>
> And this works but it is not been overwritten by my class. Any suggestions
> as Im lost to why its not been overwritten.
>
> Lodle
>
> --
>
> ___
> 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

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Panels not playing nice.

[Adam Maras (memzero)]

Try making them virtual functions.

//   Adam Maras (memzero)

Mark Chandler wrote:

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Hey guys got this problem that shouldn't be atm.

Ok I made a new vgui class based from the vgui::panel class:
class PD_BasePanel : public vgui::Panel

now in that class I have overwritten the OnMousePressed and
OnMouseDoublePressed functions:

void OnMousePressed(MouseCode code)
{
if (code == MOUSE_LEFT)
{
PostActionSignal(new KeyValues("ItemClick","name",
this->GetName()));
}
}
void OnMouseDoublePressed(MouseCode code)
{
Msg("XXX Code is: %d \n", code);
if (code == MOUSE_LEFT)
{
PostActionSignal(new
KeyValues("ItemDoubleClick","name", this->GetName()));
}
}

However the OnMousePressed function works like a charm but
OnMouseDoublePressed doesn't work at all. So I went and put a msg into the
panel.cpp OnMouseDoublePressed function:

void Panel::OnMouseDoublePressed(MouseCode code)
{
Msg("Mouse Doubled Pressed Base class \n");
}

And this works but it is not been overwritten by my class. Any suggestions
as Im lost to why its not been overwritten.

Lodle

--

___
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

[hlcoders] [hlcoders]Unproject 2D to world 3D / mouse coordinates to world

[C.Sneyd]

Hi
I have been looking into converting 2D screen coordinates into 3D World 
coordinates. I have using a method based on spherical and cylindrical 
coordinates. Is there a function like Unproject   I could use? Or do I
need to use a method based on sweeping a trace line around the world
And using Screentransform function?



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date: 29/01/2008 
22:20


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Portal

[Daniel Glenn]

--
[ Picked text/plain from multipart/alternative ]
Search around the code as it is. ;)

On Jan 30, 2008 1:14 AM, Brett Wilkins <[EMAIL PROTECTED]> wrote:

> Hey there,
>
> Is there any plan to put Portal Code into the Source SDK? My friends and
> I were wanting to make a mod and add some stuff in.
>
> Cheers,
>
> Brett
>
> --
> **
> Brett Wilkins
> A.K.A Beedub
> The Fixit
>
>
> ___
> 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

Re: [hlcoders] Portal

[Qazzian]

[ Converted text/html to text/plain ]
All I can find are files related to area portals.
I was at least expecting a "weapon_portalgun" class
Daniel Glenn wrote:

--
[ Picked text/plain from multipart/alternative ]
Search around the code as it is. ;)

On Jan 30, 2008 1:14 AM, Brett Wilkins <[EMAIL PROTECTED]>[1] wrote:



Hey there,

Is there any plan to put Portal Code into the Source SDK? My friends and
I were wanting to make a mod and add some stuff in.

Cheers,

Brett

--
**
Brett Wilkins
A.K.A Beedub
The Fixit


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders[2]




--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders[3]




===References:===
  1. mailto:[EMAIL PROTECTED]
  2. http://list.valvesoftware.com/mailman/listinfo/hlcoders
  3. 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

RE: [hlcoders] Panels not playing nice.

[Maarten De Meyer]

Did you make the member functions in the *base* class virtual? ( cause
that is what he meant ).

> Same result
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Adam Maras
> (memzero)
> Sent: Wednesday, January 30, 2008 10:38 PM
> To: hlcoders@list.valvesoftware.com
> Subject: Re: [hlcoders] Panels not playing nice.
>
> Try making them virtual functions.
>
> //   Adam Maras (memzero)
>
> Mark Chandler wrote:
>> This is a multipart message in MIME format.
>> --
>> [ Picked text/plain from multipart/alternative ]
>> Hey guys got this problem that shouldn't be atm.
>>
>> Ok I made a new vgui class based from the vgui::panel class:
>>  class PD_BasePanel : public vgui::Panel
>>
>> now in that class I have overwritten the OnMousePressed and
>> OnMouseDoublePressed functions:
>>
>>  void OnMousePressed(MouseCode code)
>>  {
>>  if (code == MOUSE_LEFT)
>>  {
>>  PostActionSignal(new KeyValues("ItemClick","name",
>> this->GetName()));
>>  }
>>  }
>>  void OnMouseDoublePressed(MouseCode code)
>>  {
>>  Msg("XXX Code is: %d \n", code);
>>  if (code == MOUSE_LEFT)
>>  {
>>  PostActionSignal(new
>> KeyValues("ItemDoubleClick","name", this->GetName()));
>>  }
>>  }
>>
>> However the OnMousePressed function works like a charm but
>> OnMouseDoublePressed doesn't work at all. So I went and put a msg into
>> the
>> panel.cpp OnMouseDoublePressed function:
>>
>> void Panel::OnMouseDoublePressed(MouseCode code)
>> {
>>  Msg("Mouse Doubled Pressed Base class \n");
>> }
>>
>> And this works but it is not been overwritten by my class. Any
>> suggestions
>> as Im lost to why its not been overwritten.
>>
>> Lodle
>>
>> --
>>
>> ___
>> 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
>
> ___
> 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

RE: [hlcoders] Panels not playing nice.

[Mark Chandler]

Its in panel.cpp which is virtual (be stupid otherwise because all its code
is { } ).



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maarten De Meyer
Sent: Thursday, January 31, 2008 1:57 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Panels not playing nice.

Did you make the member functions in the *base* class virtual? ( cause
that is what he meant ).

> Same result
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Adam Maras
> (memzero)
> Sent: Wednesday, January 30, 2008 10:38 PM
> To: hlcoders@list.valvesoftware.com
> Subject: Re: [hlcoders] Panels not playing nice.
>
> Try making them virtual functions.
>
> //   Adam Maras (memzero)
>
> Mark Chandler wrote:
>> This is a multipart message in MIME format.
>> --
>> [ Picked text/plain from multipart/alternative ]
>> Hey guys got this problem that shouldn't be atm.
>>
>> Ok I made a new vgui class based from the vgui::panel class:
>>  class PD_BasePanel : public vgui::Panel
>>
>> now in that class I have overwritten the OnMousePressed and
>> OnMouseDoublePressed functions:
>>
>>  void OnMousePressed(MouseCode code)
>>  {
>>  if (code == MOUSE_LEFT)
>>  {
>>  PostActionSignal(new KeyValues("ItemClick","name",
>> this->GetName()));
>>  }
>>  }
>>  void OnMouseDoublePressed(MouseCode code)
>>  {
>>  Msg("XXX Code is: %d \n", code);
>>  if (code == MOUSE_LEFT)
>>  {
>>  PostActionSignal(new
>> KeyValues("ItemDoubleClick","name", this->GetName()));
>>  }
>>  }
>>
>> However the OnMousePressed function works like a charm but
>> OnMouseDoublePressed doesn't work at all. So I went and put a msg into
>> the
>> panel.cpp OnMouseDoublePressed function:
>>
>> void Panel::OnMouseDoublePressed(MouseCode code)
>> {
>>  Msg("Mouse Doubled Pressed Base class \n");
>> }
>>
>> And this works but it is not been overwritten by my class. Any
>> suggestions
>> as Im lost to why its not been overwritten.
>>
>> Lodle
>>
>> --
>>
>> ___
>> 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
>
> ___
> 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

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] [hlcoders]Unproject 2D to world 3D / mouse coordinates to world

[Mulchman]

There's a "GetVectorInScreenSpace( vecPlayerOrigin, iScreenX, iScreenY )"
function you could use for taking a world position and getting screen
coordinates for it.

Also, if you search the archives Yahn posted code for mouse picking objects
on the HUD and finding corresponding world coordinates for the objects being
picked.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, January 30, 2008 05:46
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] [hlcoders]Unproject 2D to world 3D / mouse coordinates
to world


Hi
I have been looking into converting 2D screen coordinates into 3D World
coordinates. I have using a method based on spherical and cylindrical
coordinates. Is there a function like Unproject   I could use? Or do I
need to use a method based on sweeping a trace line around the world
And using Screentransform function?



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date: 29/01/2008
22:20


___
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

[hlcoders] “Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE.”

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
 Hello all. This is my first email to the mailing list and I'm writing
because I'm really stuck and hope someone can help me out. When I place an
entity and try to load my custom character it causes Hammer to crash and
displays this error message:

 "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up
VERTEX_BUFFER_SIZE."

I tried lowering the poly and vertex counts and finally got a model to load
but is way below the level of detail I need. I tried several versions of the
model with varying poly and vertex counts and noticed that the first number
in the error message (26791 in this case) would change as the poly and vert
counts change. Also, the high poly model will load fine in Face Poser.

I've tried to research the problem online and haven't found anything too
helpful. The Valve Wiki says I probably have a bug in my code or content,
which doesn't really help me too much. I also got advice to optimize my map
to reduce the vertices but I get the same error message when I try to load
the model in a simple room.


So, basically I guess I am asking if anyone knows how I can "up
VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
don't have access to a programmer so I'm hoping someone here can help me
out. Thanks for taking the time to read this and any ideas or suggestions
are greatly appreciated!

Ben
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFE R_SIZE."

[Mark Chandler]

Basically the number is current and max (26791>24576) and your model detail
is to high and will crash the engine. I don't think you can change it
without recompiling hammer and the engine.

Why you need that much detail?



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
Sent: Thursday, January 31, 2008 4:52 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell
a programmer to up VERTEX_BUFFER_SIZE."

--
[ Picked text/plain from multipart/alternative ]
 Hello all. This is my first email to the mailing list and I'm writing
because I'm really stuck and hope someone can help me out. When I place an
entity and try to load my custom character it causes Hammer to crash and
displays this error message:

 "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up
VERTEX_BUFFER_SIZE."

I tried lowering the poly and vertex counts and finally got a model to load
but is way below the level of detail I need. I tried several versions of the
model with varying poly and vertex counts and noticed that the first number
in the error message (26791 in this case) would change as the poly and vert
counts change. Also, the high poly model will load fine in Face Poser.

I've tried to research the problem online and haven't found anything too
helpful. The Valve Wiki says I probably have a bug in my code or content,
which doesn't really help me too much. I also got advice to optimize my map
to reduce the vertices but I get the same error message when I try to load
the model in a simple room.


So, basically I guess I am asking if anyone knows how I can "up
VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
don't have access to a programmer so I'm hoping someone here can help me
out. Thanks for taking the time to read this and any ideas or suggestions
are greatly appreciated!

Ben
--

___
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

[hlcoders] Re: [hlcoders] “Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE.”

[Jeremy]

--
[ Picked text/plain from multipart/alternative ]
How many polys is your model?

On Jan 30, 2008 11:51 AM, Ben Mears <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
>  Hello all. This is my first email to the mailing list and I'm writing
> because I'm really stuck and hope someone can help me out. When I place an
> entity and try to load my custom character it causes Hammer to crash and
> displays this error message:
>
>  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
> up
> VERTEX_BUFFER_SIZE."
>
> I tried lowering the poly and vertex counts and finally got a model to
> load
> but is way below the level of detail I need. I tried several versions of
> the
> model with varying poly and vertex counts and noticed that the first
> number
> in the error message (26791 in this case) would change as the poly and
> vert
> counts change. Also, the high poly model will load fine in Face Poser.
>
> I've tried to research the problem online and haven't found anything too
> helpful. The Valve Wiki says I probably have a bug in my code or content,
> which doesn't really help me too much. I also got advice to optimize my
> map
> to reduce the vertices but I get the same error message when I try to load
> the model in a simple room.
>
>
> So, basically I guess I am asking if anyone knows how I can "up
> VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
> don't have access to a programmer so I'm hoping someone here can help me
> out. Thanks for taking the time to read this and any ideas or suggestions
> are greatly appreciated!
>
> Ben
> --
>
> ___
> 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

[hlcoders] Re: [hlcoders] Re: [hlcoders] “Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE.”

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
The optimal amount of polys that I would like to have is around 11,000 but
to make it work in-game I need to drop it down to around 5,000 or so. I'm
still testing out the highest amount of polys I can have before I get that
error message.

On Jan 30, 2008 12:01 PM, Jeremy <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> How many polys is your model?
>
> On Jan 30, 2008 11:51 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> >  Hello all. This is my first email to the mailing list and I'm writing
> > because I'm really stuck and hope someone can help me out. When I place
> an
> > entity and try to load my custom character it causes Hammer to crash and
> > displays this error message:
> >
> >  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
> > up
> > VERTEX_BUFFER_SIZE."
> >
> > I tried lowering the poly and vertex counts and finally got a model to
> > load
> > but is way below the level of detail I need. I tried several versions of
> > the
> > model with varying poly and vertex counts and noticed that the first
> > number
> > in the error message (26791 in this case) would change as the poly and
> > vert
> > counts change. Also, the high poly model will load fine in Face Poser.
> >
> > I've tried to research the problem online and haven't found anything too
> > helpful. The Valve Wiki says I probably have a bug in my code or
> content,
> > which doesn't really help me too much. I also got advice to optimize my
> > map
> > to reduce the vertices but I get the same error message when I try to
> load
> > the model in a simple room.
> >
> >
> > So, basically I guess I am asking if anyone knows how I can "up
> > VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
> > don't have access to a programmer so I'm hoping someone here can help me
> > out. Thanks for taking the time to read this and any ideas or
> suggestions
> > are greatly appreciated!
> >
> > Ben
> > --
> >
> > ___
> > 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
>
>
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jeremy]

--
[ Picked text/plain from multipart/alternative ]
You can't. That's something Valve would have to do afaik. That sort of
detail level isn't very practical for the generation of game engine that
Source is. Maybe you can split it up into multiple parts, where each part
doesn't exceed the total, like separating the armor or accessories. I think
Unreal Engine 3 doesn't even push that high of a detail on their character
models. These days you generally fake most of it with normal maps and such.

J


On Jan 30, 2008 12:18 PM, Ben Mears <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Well, it's a pretty detailed model with a lot of armor and accessories.
> I'm
> happy with the model at about 11,000 polys but when I bring it down to
> around 5,000 to make it work in game it starts to look pretty bad. Polys
> get
> removed from spots where they need to be, such as his eyes. So, you said
> you
> can't change it without recompiling Hammer and the engine? How would I go
> about doing that?
>
> Thanks for the help Mark.
>
>
> On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
>
> > Basically the number is current and max (26791>24576) and your model
> > detail
> > is to high and will crash the engine. I don't think you can change it
> > without recompiling hammer and the engine.
> >
> > Why you need that much detail?
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > Sent: Thursday, January 31, 2008 4:52 AM
> > To: hlcoders@list.valvesoftware.com
> > Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> > Tell
> > a programmer to up VERTEX_BUFFER_SIZE."
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> >  Hello all. This is my first email to the mailing list and I'm writing
> > because I'm really stuck and hope someone can help me out. When I place
> an
> > entity and try to load my custom character it causes Hammer to crash and
> > displays this error message:
> >
> >  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
> > up
> > VERTEX_BUFFER_SIZE."
> >
> > I tried lowering the poly and vertex counts and finally got a model to
> > load
> > but is way below the level of detail I need. I tried several versions of
> > the
> > model with varying poly and vertex counts and noticed that the first
> > number
> > in the error message (26791 in this case) would change as the poly and
> > vert
> > counts change. Also, the high poly model will load fine in Face Poser.
> >
> > I've tried to research the problem online and haven't found anything too
> > helpful. The Valve Wiki says I probably have a bug in my code or
> content,
> > which doesn't really help me too much. I also got advice to optimize my
> > map
> > to reduce the vertices but I get the same error message when I try to
> load
> > the model in a simple room.
> >
> >
> > So, basically I guess I am asking if anyone knows how I can "up
> > VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
> > don't have access to a programmer so I'm hoping someone here can help me
> > out. Thanks for taking the time to read this and any ideas or
> suggestions
> > are greatly appreciated!
> >
> > Ben
> > --
> >
> > ___
> > 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
> >
> >
> --
>
> ___
> 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

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Adam Maras (memzero)]

So, you said you
can't change it without recompiling Hammer and the engine? How would I go
about doing that?

You don't. The limits are imposed because the Source engine itself would
choke on a model with that much detail. Is there any way you could make
the armor and/or accessories separate models and attach them at runtime?

//   Adam Maras (memzero)

Ben Mears wrote:

--
[ Picked text/plain from multipart/alternative ]
Well, it's a pretty detailed model with a lot of armor and accessories. I'm
happy with the model at about 11,000 polys but when I bring it down to
around 5,000 to make it work in game it starts to look pretty bad. Polys get
removed from spots where they need to be, such as his eyes. So, you said you
can't change it without recompiling Hammer and the engine? How would I go
about doing that?

Thanks for the help Mark.


On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:



Basically the number is current and max (26791>24576) and your model
detail
is to high and will crash the engine. I don't think you can change it
without recompiling hammer and the engine.

Why you need that much detail?



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
Sent: Thursday, January 31, 2008 4:52 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
Tell
a programmer to up VERTEX_BUFFER_SIZE."

--
[ Picked text/plain from multipart/alternative ]
 Hello all. This is my first email to the mailing list and I'm writing
because I'm really stuck and hope someone can help me out. When I place an
entity and try to load my custom character it causes Hammer to crash and
displays this error message:

 "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
up
VERTEX_BUFFER_SIZE."

I tried lowering the poly and vertex counts and finally got a model to
load
but is way below the level of detail I need. I tried several versions of
the
model with varying poly and vertex counts and noticed that the first
number
in the error message (26791 in this case) would change as the poly and
vert
counts change. Also, the high poly model will load fine in Face Poser.

I've tried to research the problem online and haven't found anything too
helpful. The Valve Wiki says I probably have a bug in my code or content,
which doesn't really help me too much. I also got advice to optimize my
map
to reduce the vertices but I get the same error message when I try to load
the model in a simple room.


So, basically I guess I am asking if anyone knows how I can "up
VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
don't have access to a programmer so I'm hoping someone here can help me
out. Thanks for taking the time to read this and any ideas or suggestions
are greatly appreciated!

Ben
--

___
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




--

___
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

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
Well, it's a pretty detailed model with a lot of armor and accessories. I'm
happy with the model at about 11,000 polys but when I bring it down to
around 5,000 to make it work in game it starts to look pretty bad. Polys get
removed from spots where they need to be, such as his eyes. So, you said you
can't change it without recompiling Hammer and the engine? How would I go
about doing that?

Thanks for the help Mark.


On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:

> Basically the number is current and max (26791>24576) and your model
> detail
> is to high and will crash the engine. I don't think you can change it
> without recompiling hammer and the engine.
>
> Why you need that much detail?
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> Sent: Thursday, January 31, 2008 4:52 AM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> Tell
> a programmer to up VERTEX_BUFFER_SIZE."
>
> --
> [ Picked text/plain from multipart/alternative ]
>  Hello all. This is my first email to the mailing list and I'm writing
> because I'm really stuck and hope someone can help me out. When I place an
> entity and try to load my custom character it causes Hammer to crash and
> displays this error message:
>
>  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
> up
> VERTEX_BUFFER_SIZE."
>
> I tried lowering the poly and vertex counts and finally got a model to
> load
> but is way below the level of detail I need. I tried several versions of
> the
> model with varying poly and vertex counts and noticed that the first
> number
> in the error message (26791 in this case) would change as the poly and
> vert
> counts change. Also, the high poly model will load fine in Face Poser.
>
> I've tried to research the problem online and haven't found anything too
> helpful. The Valve Wiki says I probably have a bug in my code or content,
> which doesn't really help me too much. I also got advice to optimize my
> map
> to reduce the vertices but I get the same error message when I try to load
> the model in a simple room.
>
>
> So, basically I guess I am asking if anyone knows how I can "up
> VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
> don't have access to a programmer so I'm hoping someone here can help me
> out. Thanks for taking the time to read this and any ideas or suggestions
> are greatly appreciated!
>
> Ben
> --
>
> ___
> 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
>
>
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jed]

You tried normal maps?

I think the largest poly-count model I've seen in a Source game is the
Tiger tank in DoD which is ~11000 max.

- Jed

On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> --
> [ Picked text/plain from multipart/alternative ]
> Well, it's a pretty detailed model with a lot of armor and accessories. I'm
> happy with the model at about 11,000 polys but when I bring it down to
> around 5,000 to make it work in game it starts to look pretty bad. Polys get
> removed from spots where they need to be, such as his eyes. So, you said you
> can't change it without recompiling Hammer and the engine? How would I go
> about doing that?
>
> Thanks for the help Mark.
>
>
> On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
>
> > Basically the number is current and max (26791>24576) and your model
> > detail
> > is to high and will crash the engine. I don't think you can change it
> > without recompiling hammer and the engine.
> >
> > Why you need that much detail?
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > Sent: Thursday, January 31, 2008 4:52 AM
> > To: hlcoders@list.valvesoftware.com
> > Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> > Tell
> > a programmer to up VERTEX_BUFFER_SIZE."
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> >  Hello all. This is my first email to the mailing list and I'm writing
> > because I'm really stuck and hope someone can help me out. When I place an
> > entity and try to load my custom character it causes Hammer to crash and
> > displays this error message:
> >
> >  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
> > up
> > VERTEX_BUFFER_SIZE."
> >
> > I tried lowering the poly and vertex counts and finally got a model to
> > load
> > but is way below the level of detail I need. I tried several versions of
> > the
> > model with varying poly and vertex counts and noticed that the first
> > number
> > in the error message (26791 in this case) would change as the poly and
> > vert
> > counts change. Also, the high poly model will load fine in Face Poser.
> >
> > I've tried to research the problem online and haven't found anything too
> > helpful. The Valve Wiki says I probably have a bug in my code or content,
> > which doesn't really help me too much. I also got advice to optimize my
> > map
> > to reduce the vertices but I get the same error message when I try to load
> > the model in a simple room.
> >
> >
> > So, basically I guess I am asking if anyone knows how I can "up
> > VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
> > don't have access to a programmer so I'm hoping someone here can help me
> > out. Thanks for taking the time to read this and any ideas or suggestions
> > are greatly appreciated!
> >
> > Ben
> > --
> >
> > ___
> > 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
> >
> >
> --
>
> ___
> 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

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
Yep, I'm using normal maps. I've had models with 10,000 - 15,000 polys that
worked fine so I really don't think that I have too many polys on this guy.

On Jan 30, 2008 12:41 PM, Jed <[EMAIL PROTECTED]> wrote:

> You tried normal maps?
>
> I think the largest poly-count model I've seen in a Source game is the
> Tiger tank in DoD which is ~11000 max.
>
> - Jed
>
> On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Well, it's a pretty detailed model with a lot of armor and accessories.
> I'm
> > happy with the model at about 11,000 polys but when I bring it down to
> > around 5,000 to make it work in game it starts to look pretty bad. Polys
> get
> > removed from spots where they need to be, such as his eyes. So, you said
> you
> > can't change it without recompiling Hammer and the engine? How would I
> go
> > about doing that?
> >
> > Thanks for the help Mark.
> >
> >
> > On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> >
> > > Basically the number is current and max (26791>24576) and your model
> > > detail
> > > is to high and will crash the engine. I don't think you can change it
> > > without recompiling hammer and the engine.
> > >
> > > Why you need that much detail?
> > >
> > >
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > > Sent: Thursday, January 31, 2008 4:52 AM
> > > To: hlcoders@list.valvesoftware.com
> > > Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> > > Tell
> > > a programmer to up VERTEX_BUFFER_SIZE."
> > >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > >  Hello all. This is my first email to the mailing list and I'm writing
> > > because I'm really stuck and hope someone can help me out. When I
> place an
> > > entity and try to load my custom character it causes Hammer to crash
> and
> > > displays this error message:
> > >
> > >  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer
> to
> > > up
> > > VERTEX_BUFFER_SIZE."
> > >
> > > I tried lowering the poly and vertex counts and finally got a model to
> > > load
> > > but is way below the level of detail I need. I tried several versions
> of
> > > the
> > > model with varying poly and vertex counts and noticed that the first
> > > number
> > > in the error message (26791 in this case) would change as the poly and
> > > vert
> > > counts change. Also, the high poly model will load fine in Face Poser.
> > >
> > > I've tried to research the problem online and haven't found anything
> too
> > > helpful. The Valve Wiki says I probably have a bug in my code or
> content,
> > > which doesn't really help me too much. I also got advice to optimize
> my
> > > map
> > > to reduce the vertices but I get the same error message when I try to
> load
> > > the model in a simple room.
> > >
> > >
> > > So, basically I guess I am asking if anyone knows how I can "up
> > > VERTEX_BUFFER_SIZE"? I don't really have much experience with coding
> and
> > > don't have access to a programmer so I'm hoping someone here can help
> me
> > > out. Thanks for taking the time to read this and any ideas or
> suggestions
> > > are greatly appreciated!
> > >
> > > Ben
> > > --
> > >
> > > ___
> > > 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
> > >
> > >
> > --
> >
> > ___
> > 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
>
>
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Mark Chandler]

You send valve a check for $1 mil and you get the source code for it.

Any chance we could see a render of it. Got me interested. :D



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
Sent: Thursday, January 31, 2008 5:19 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer
(26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

--
[ Picked text/plain from multipart/alternative ]
Well, it's a pretty detailed model with a lot of armor and accessories. I'm
happy with the model at about 11,000 polys but when I bring it down to
around 5,000 to make it work in game it starts to look pretty bad. Polys get
removed from spots where they need to be, such as his eyes. So, you said you
can't change it without recompiling Hammer and the engine? How would I go
about doing that?

Thanks for the help Mark.


On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:

> Basically the number is current and max (26791>24576) and your model
> detail
> is to high and will crash the engine. I don't think you can change it
> without recompiling hammer and the engine.
>
> Why you need that much detail?
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> Sent: Thursday, January 31, 2008 4:52 AM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> Tell
> a programmer to up VERTEX_BUFFER_SIZE."
>
> --
> [ Picked text/plain from multipart/alternative ]
>  Hello all. This is my first email to the mailing list and I'm writing
> because I'm really stuck and hope someone can help me out. When I place an
> entity and try to load my custom character it causes Hammer to crash and
> displays this error message:
>
>  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
> up
> VERTEX_BUFFER_SIZE."
>
> I tried lowering the poly and vertex counts and finally got a model to
> load
> but is way below the level of detail I need. I tried several versions of
> the
> model with varying poly and vertex counts and noticed that the first
> number
> in the error message (26791 in this case) would change as the poly and
> vert
> counts change. Also, the high poly model will load fine in Face Poser.
>
> I've tried to research the problem online and haven't found anything too
> helpful. The Valve Wiki says I probably have a bug in my code or content,
> which doesn't really help me too much. I also got advice to optimize my
> map
> to reduce the vertices but I get the same error message when I try to load
> the model in a simple room.
>
>
> So, basically I guess I am asking if anyone knows how I can "up
> VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
> don't have access to a programmer so I'm hoping someone here can help me
> out. Thanks for taking the time to read this and any ideas or suggestions
> are greatly appreciated!
>
> Ben
> --
>
> ___
> 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
>
>
--

___
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

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jeffrey "botman" Broome]

Jeremy wrote:

I think Unreal Engine 3 doesn't even push that high of a detail on
their character models. These days you generally fake most of it with
normal maps and such.


UE3 uses a high poly model to generate normal maps and a low poly model
in the game.  See the bottom of this page for an example...

http://www.unrealtechnology.com/features.php?ref=rendering

Charaters on the order of 5,000-8,000 polys is typical.

--
Jeffrey "botman" Broome

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jeremy]

--
[ Picked text/plain from multipart/alternative ]
Was just curious about polycount. I realize technically you have too many
vertices. If vertices were shared enough you could have a large number of
polygons with a smaller number of vertices, provided you don't run into any
limit on index buffer size that may be present. In this case the error is
clearly referring to the vertices. Are the vertices welded/merged where
appropriate to reduce them as much as possible without sacrificing poly
counts? I don't doubt such high poly models probably work, and possibly
pretty well if they are by themselves on a screen or with little else. But
those sort of poly counts in a typical mod that normally has a number of
players/npcs is going to degrade quickly. It all depends what you're doing.
That degree of detail could fit your project if it's outside the norm of an
FPS mod. Just be aware what the engine was designed and built to do, as that
is the reason for the limitations it has. Short of engine level
modifications, which you can't do without getting the engine source, you'll
have to stick within those limits, and work around them if possible. Split
the model into pieces and attach them and stuff like that is probably the
direction you need to look at to keep that detail level and stay within
limits.

J

On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:

> You send valve a check for $1 mil and you get the source code for it.
>
> Any chance we could see a render of it. Got me interested. :D
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> Sent: Thursday, January 31, 2008 5:19 AM
> To: hlcoders@list.valvesoftware.com
> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic
> buffer
> (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
>
> --
> [ Picked text/plain from multipart/alternative ]
> Well, it's a pretty detailed model with a lot of armor and accessories.
> I'm
> happy with the model at about 11,000 polys but when I bring it down to
> around 5,000 to make it work in game it starts to look pretty bad. Polys
> get
> removed from spots where they need to be, such as his eyes. So, you said
> you
> can't change it without recompiling Hammer and the engine? How would I go
> about doing that?
>
> Thanks for the help Mark.
>
>
> On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
>
> > Basically the number is current and max (26791>24576) and your model
> > detail
> > is to high and will crash the engine. I don't think you can change it
> > without recompiling hammer and the engine.
> >
> > Why you need that much detail?
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > Sent: Thursday, January 31, 2008 4:52 AM
> > To: hlcoders@list.valvesoftware.com
> > Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> > Tell
> > a programmer to up VERTEX_BUFFER_SIZE."
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> >  Hello all. This is my first email to the mailing list and I'm writing
> > because I'm really stuck and hope someone can help me out. When I place
> an
> > entity and try to load my custom character it causes Hammer to crash and
> > displays this error message:
> >
> >  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
> > up
> > VERTEX_BUFFER_SIZE."
> >
> > I tried lowering the poly and vertex counts and finally got a model to
> > load
> > but is way below the level of detail I need. I tried several versions of
> > the
> > model with varying poly and vertex counts and noticed that the first
> > number
> > in the error message (26791 in this case) would change as the poly and
> > vert
> > counts change. Also, the high poly model will load fine in Face Poser.
> >
> > I've tried to research the problem online and haven't found anything too
> > helpful. The Valve Wiki says I probably have a bug in my code or
> content,
> > which doesn't really help me too much. I also got advice to optimize my
> > map
> > to reduce the vertices but I get the same error message when I try to
> load
> > the model in a simple room.
> >
> >
> > So, basically I guess I am asking if anyone knows how I can "up
> > VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
> > don't have access to a programmer so I'm hoping someone here can help me
> > out. Thanks for taking the time to read this and any ideas or
> suggestions
> > are greatly appreciated!
> >
> > Ben
> > --
> >
> > ___
> > 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/hlco

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jeremy]

--
[ Picked text/plain from multipart/alternative ]
Right. I was just looking at that. Point being nobody is running 11k
character models in current gen FPS games. If he's making something more
character centric like a fighting game that's different, but he's still
working within the limitations of an FPS engine.

J

On Jan 30, 2008 1:09 PM, Jeffrey botman Broome <[EMAIL PROTECTED]>
wrote:

> Jeremy wrote:
> > I think Unreal Engine 3 doesn't even push that high of a detail on
> > their character models. These days you generally fake most of it with
> > normal maps and such.
>
> UE3 uses a high poly model to generate normal maps and a low poly model
> in the game.  See the bottom of this page for an example...
>
> http://www.unrealtechnology.com/features.php?ref=rendering
>
> Charaters on the order of 5,000-8,000 polys is typical.
>
> --
> Jeffrey "botman" Broome
>
> ___
> 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

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
I'm getting my polycount from within XSI and at about 11,500 polys I'm
getting a vertex (or "point" in XSI) count of only 7042. Way below 24,000

On Jan 30, 2008 1:08 PM, Jed <[EMAIL PROTECTED]> wrote:

> Just a quick question - where are you getting the polycount from? Your
> modelling app or HLMV? 26000+ verts sounds about in the ballpark for a
> 15000 poly model anyway considering 3 verts per triangle even when
> many are shared.
>
> - Jed
>
> On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Yep, I'm using normal maps. I've had models with 10,000 - 15,000 polys
> that
> > worked fine so I really don't think that I have too many polys on this
> guy.
> >
> > On Jan 30, 2008 12:41 PM, Jed <[EMAIL PROTECTED]> wrote:
> >
> > > You tried normal maps?
> > >
> > > I think the largest poly-count model I've seen in a Source game is the
> > > Tiger tank in DoD which is ~11000 max.
> > >
> > > - Jed
> > >
> > > On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > Well, it's a pretty detailed model with a lot of armor and
> accessories.
> > > I'm
> > > > happy with the model at about 11,000 polys but when I bring it down
> to
> > > > around 5,000 to make it work in game it starts to look pretty bad.
> Polys
> > > get
> > > > removed from spots where they need to be, such as his eyes. So, you
> said
> > > you
> > > > can't change it without recompiling Hammer and the engine? How would
> I
> > > go
> > > > about doing that?
> > > >
> > > > Thanks for the help Mark.
> > > >
> > > >
> > > > On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Basically the number is current and max (26791>24576) and your
> model
> > > > > detail
> > > > > is to high and will crash the engine. I don't think you can change
> it
> > > > > without recompiling hammer and the engine.
> > > > >
> > > > > Why you need that much detail?
> > > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> Mears
> > > > > Sent: Thursday, January 31, 2008 4:52 AM
> > > > > To: hlcoders@list.valvesoftware.com
> > > > > Subject: [hlcoders] "Too many verts for a dynamic buffer
> (26791>24576)
> > > > > Tell
> > > > > a programmer to up VERTEX_BUFFER_SIZE."
> > > > >
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > >  Hello all. This is my first email to the mailing list and I'm
> writing
> > > > > because I'm really stuck and hope someone can help me out. When I
> > > place an
> > > > > entity and try to load my custom character it causes Hammer to
> crash
> > > and
> > > > > displays this error message:
> > > > >
> > > > >  "Too many verts for a dynamic buffer (26791>24576) Tell a
> programmer
> > > to
> > > > > up
> > > > > VERTEX_BUFFER_SIZE."
> > > > >
> > > > > I tried lowering the poly and vertex counts and finally got a
> model to
> > > > > load
> > > > > but is way below the level of detail I need. I tried several
> versions
> > > of
> > > > > the
> > > > > model with varying poly and vertex counts and noticed that the
> first
> > > > > number
> > > > > in the error message (26791 in this case) would change as the poly
> and
> > > > > vert
> > > > > counts change. Also, the high poly model will load fine in Face
> Poser.
> > > > >
> > > > > I've tried to research the problem online and haven't found
> anything
> > > too
> > > > > helpful. The Valve Wiki says I probably have a bug in my code or
> > > content,
> > > > > which doesn't really help me too much. I also got advice to
> optimize
> > > my
> > > > > map
> > > > > to reduce the vertices but I get the same error message when I try
> to
> > > load
> > > > > the model in a simple room.
> > > > >
> > > > >
> > > > > So, basically I guess I am asking if anyone knows how I can "up
> > > > > VERTEX_BUFFER_SIZE"? I don't really have much experience with
> coding
> > > and
> > > > > don't have access to a programmer so I'm hoping someone here can
> help
> > > me
> > > > > out. Thanks for taking the time to read this and any ideas or
> > > suggestions
> > > > > are greatly appreciated!
> > > > >
> > > > > Ben
> > > > > --
> > > > >
> > > > > ___
> > > > > 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
> > > > >
> > > > >
> > > > --
> > > >
> > > > ___
> > > > To unsubscribe, edit your list preferences, or view the list
> ar

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Julian Moschüring]

Well, citadelpart8.mdl from ep2 has 28000 polys and gives the same error
message in hammer:
"Too many verts for a dynamic buffer (41468>24576) Tell a programmer to
up VERTEX_BUFFER_SIZE."
But it's in game so I guess it is only a limitation of hammer. The model
will propably load if set at runtime.
-archy

Jeremy wrote:

--
[ Picked text/plain from multipart/alternative ]
Was just curious about polycount. I realize technically you have too many
vertices. If vertices were shared enough you could have a large number of
polygons with a smaller number of vertices, provided you don't run into any
limit on index buffer size that may be present. In this case the error is
clearly referring to the vertices. Are the vertices welded/merged where
appropriate to reduce them as much as possible without sacrificing poly
counts? I don't doubt such high poly models probably work, and possibly
pretty well if they are by themselves on a screen or with little else. But
those sort of poly counts in a typical mod that normally has a number of
players/npcs is going to degrade quickly. It all depends what you're doing.
That degree of detail could fit your project if it's outside the norm of an
FPS mod. Just be aware what the engine was designed and built to do, as that
is the reason for the limitations it has. Short of engine level
modifications, which you can't do without getting the engine source, you'll
have to stick within those limits, and work around them if possible. Split
the model into pieces and attach them and stuff like that is probably the
direction you need to look at to keep that detail level and stay within
limits.

J

On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:



You send valve a check for $1 mil and you get the source code for it.

Any chance we could see a render of it. Got me interested. :D



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
Sent: Thursday, January 31, 2008 5:19 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic
buffer
(26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

--
[ Picked text/plain from multipart/alternative ]
Well, it's a pretty detailed model with a lot of armor and accessories.
I'm
happy with the model at about 11,000 polys but when I bring it down to
around 5,000 to make it work in game it starts to look pretty bad. Polys
get
removed from spots where they need to be, such as his eyes. So, you said
you
can't change it without recompiling Hammer and the engine? How would I go
about doing that?

Thanks for the help Mark.


On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:



Basically the number is current and max (26791>24576) and your model
detail
is to high and will crash the engine. I don't think you can change it
without recompiling hammer and the engine.

Why you need that much detail?



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
Sent: Thursday, January 31, 2008 4:52 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
Tell
a programmer to up VERTEX_BUFFER_SIZE."

--
[ Picked text/plain from multipart/alternative ]
 Hello all. This is my first email to the mailing list and I'm writing
because I'm really stuck and hope someone can help me out. When I place


an


entity and try to load my custom character it causes Hammer to crash and
displays this error message:

 "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to
up
VERTEX_BUFFER_SIZE."

I tried lowering the poly and vertex counts and finally got a model to
load
but is way below the level of detail I need. I tried several versions of
the
model with varying poly and vertex counts and noticed that the first
number
in the error message (26791 in this case) would change as the poly and
vert
counts change. Also, the high poly model will load fine in Face Poser.

I've tried to research the problem online and haven't found anything too
helpful. The Valve Wiki says I probably have a bug in my code or


content,


which doesn't really help me too much. I also got advice to optimize my
map
to reduce the vertices but I get the same error message when I try to


load


the model in a simple room.


So, basically I guess I am asking if anyone knows how I can "up
VERTEX_BUFFER_SIZE"? I don't really have much experience with coding and
don't have access to a programmer so I'm hoping someone here can help me
out. Thanks for taking the time to read this and any ideas or


suggestions


are greatly appreciated!

Ben
--

___
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.valves

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jeremy]

--
[ Picked text/plain from multipart/alternative ]
Wierd. Maybe the exporter is crap and exports shared verts as unique or
something.

On Jan 30, 2008 1:21 PM, Ben Mears <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> I'm getting my polycount from within XSI and at about 11,500 polys I'm
> getting a vertex (or "point" in XSI) count of only 7042. Way below 24,000
>
> On Jan 30, 2008 1:08 PM, Jed <[EMAIL PROTECTED]> wrote:
>
> > Just a quick question - where are you getting the polycount from? Your
> > modelling app or HLMV? 26000+ verts sounds about in the ballpark for a
> > 15000 poly model anyway considering 3 verts per triangle even when
> > many are shared.
> >
> > - Jed
> >
> > On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Yep, I'm using normal maps. I've had models with 10,000 - 15,000 polys
> > that
> > > worked fine so I really don't think that I have too many polys on this
> > guy.
> > >
> > > On Jan 30, 2008 12:41 PM, Jed <[EMAIL PROTECTED]> wrote:
> > >
> > > > You tried normal maps?
> > > >
> > > > I think the largest poly-count model I've seen in a Source game is
> the
> > > > Tiger tank in DoD which is ~11000 max.
> > > >
> > > > - Jed
> > > >
> > > > On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > > Well, it's a pretty detailed model with a lot of armor and
> > accessories.
> > > > I'm
> > > > > happy with the model at about 11,000 polys but when I bring it
> down
> > to
> > > > > around 5,000 to make it work in game it starts to look pretty bad.
> > Polys
> > > > get
> > > > > removed from spots where they need to be, such as his eyes. So,
> you
> > said
> > > > you
> > > > > can't change it without recompiling Hammer and the engine? How
> would
> > I
> > > > go
> > > > > about doing that?
> > > > >
> > > > > Thanks for the help Mark.
> > > > >
> > > > >
> > > > > On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Basically the number is current and max (26791>24576) and your
> > model
> > > > > > detail
> > > > > > is to high and will crash the engine. I don't think you can
> change
> > it
> > > > > > without recompiling hammer and the engine.
> > > > > >
> > > > > > Why you need that much detail?
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: [EMAIL PROTECTED]
> > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> > Mears
> > > > > > Sent: Thursday, January 31, 2008 4:52 AM
> > > > > > To: hlcoders@list.valvesoftware.com
> > > > > > Subject: [hlcoders] "Too many verts for a dynamic buffer
> > (26791>24576)
> > > > > > Tell
> > > > > > a programmer to up VERTEX_BUFFER_SIZE."
> > > > > >
> > > > > > --
> > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > >  Hello all. This is my first email to the mailing list and I'm
> > writing
> > > > > > because I'm really stuck and hope someone can help me out. When
> I
> > > > place an
> > > > > > entity and try to load my custom character it causes Hammer to
> > crash
> > > > and
> > > > > > displays this error message:
> > > > > >
> > > > > >  "Too many verts for a dynamic buffer (26791>24576) Tell a
> > programmer
> > > > to
> > > > > > up
> > > > > > VERTEX_BUFFER_SIZE."
> > > > > >
> > > > > > I tried lowering the poly and vertex counts and finally got a
> > model to
> > > > > > load
> > > > > > but is way below the level of detail I need. I tried several
> > versions
> > > > of
> > > > > > the
> > > > > > model with varying poly and vertex counts and noticed that the
> > first
> > > > > > number
> > > > > > in the error message (26791 in this case) would change as the
> poly
> > and
> > > > > > vert
> > > > > > counts change. Also, the high poly model will load fine in Face
> > Poser.
> > > > > >
> > > > > > I've tried to research the problem online and haven't found
> > anything
> > > > too
> > > > > > helpful. The Valve Wiki says I probably have a bug in my code or
> > > > content,
> > > > > > which doesn't really help me too much. I also got advice to
> > optimize
> > > > my
> > > > > > map
> > > > > > to reduce the vertices but I get the same error message when I
> try
> > to
> > > > load
> > > > > > the model in a simple room.
> > > > > >
> > > > > >
> > > > > > So, basically I guess I am asking if anyone knows how I can "up
> > > > > > VERTEX_BUFFER_SIZE"? I don't really have much experience with
> > coding
> > > > and
> > > > > > don't have access to a programmer so I'm hoping someone here can
> > help
> > > > me
> > > > > > out. Thanks for taking the time to read this and any ideas or
> > > > suggestions
> > > > > > are greatly appreciated!
> > > > > >
> > > > > > Ben
> > > > > > --
> > > > > >
> > > > > > ___
> > > > > > To unsubscribe, edit your list preferences, or view the list
> > archives,
> 

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jed]

Just a quick question - where are you getting the polycount from? Your
modelling app or HLMV? 26000+ verts sounds about in the ballpark for a
15000 poly model anyway considering 3 verts per triangle even when
many are shared.

- Jed

On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> --
> [ Picked text/plain from multipart/alternative ]
> Yep, I'm using normal maps. I've had models with 10,000 - 15,000 polys that
> worked fine so I really don't think that I have too many polys on this guy.
>
> On Jan 30, 2008 12:41 PM, Jed <[EMAIL PROTECTED]> wrote:
>
> > You tried normal maps?
> >
> > I think the largest poly-count model I've seen in a Source game is the
> > Tiger tank in DoD which is ~11000 max.
> >
> > - Jed
> >
> > On 30/01/2008, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Well, it's a pretty detailed model with a lot of armor and accessories.
> > I'm
> > > happy with the model at about 11,000 polys but when I bring it down to
> > > around 5,000 to make it work in game it starts to look pretty bad. Polys
> > get
> > > removed from spots where they need to be, such as his eyes. So, you said
> > you
> > > can't change it without recompiling Hammer and the engine? How would I
> > go
> > > about doing that?
> > >
> > > Thanks for the help Mark.
> > >
> > >
> > > On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > >
> > > > Basically the number is current and max (26791>24576) and your model
> > > > detail
> > > > is to high and will crash the engine. I don't think you can change it
> > > > without recompiling hammer and the engine.
> > > >
> > > > Why you need that much detail?
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > > > Sent: Thursday, January 31, 2008 4:52 AM
> > > > To: hlcoders@list.valvesoftware.com
> > > > Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> > > > Tell
> > > > a programmer to up VERTEX_BUFFER_SIZE."
> > > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > >  Hello all. This is my first email to the mailing list and I'm writing
> > > > because I'm really stuck and hope someone can help me out. When I
> > place an
> > > > entity and try to load my custom character it causes Hammer to crash
> > and
> > > > displays this error message:
> > > >
> > > >  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer
> > to
> > > > up
> > > > VERTEX_BUFFER_SIZE."
> > > >
> > > > I tried lowering the poly and vertex counts and finally got a model to
> > > > load
> > > > but is way below the level of detail I need. I tried several versions
> > of
> > > > the
> > > > model with varying poly and vertex counts and noticed that the first
> > > > number
> > > > in the error message (26791 in this case) would change as the poly and
> > > > vert
> > > > counts change. Also, the high poly model will load fine in Face Poser.
> > > >
> > > > I've tried to research the problem online and haven't found anything
> > too
> > > > helpful. The Valve Wiki says I probably have a bug in my code or
> > content,
> > > > which doesn't really help me too much. I also got advice to optimize
> > my
> > > > map
> > > > to reduce the vertices but I get the same error message when I try to
> > load
> > > > the model in a simple room.
> > > >
> > > >
> > > > So, basically I guess I am asking if anyone knows how I can "up
> > > > VERTEX_BUFFER_SIZE"? I don't really have much experience with coding
> > and
> > > > don't have access to a programmer so I'm hoping someone here can help
> > me
> > > > out. Thanks for taking the time to read this and any ideas or
> > suggestions
> > > > are greatly appreciated!
> > > >
> > > > Ben
> > > > --
> > > >
> > > > ___
> > > > 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
> > > >
> > > >
> > > --
> > >
> > > ___
> > > 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
> >
> >
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

__

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
Thanks for the info Jeremy. I'm actually using this character for a
machinima movie and there are a lot of other characters, props, scripted
sequences etc. in the map so I think you may be right about overloading the
engine. The verts on the model are set up really well it's just that there
is a lot of them. Chris had an idea about working with the collision model
and I think that's what I'm going to work on next. Thanks a lot for the help
guys and any other ideas or suggestions are always appreciated!!

On Jan 30, 2008 1:09 PM, Jeremy <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Was just curious about polycount. I realize technically you have too many
> vertices. If vertices were shared enough you could have a large number of
> polygons with a smaller number of vertices, provided you don't run into
> any
> limit on index buffer size that may be present. In this case the error is
> clearly referring to the vertices. Are the vertices welded/merged where
> appropriate to reduce them as much as possible without sacrificing poly
> counts? I don't doubt such high poly models probably work, and possibly
> pretty well if they are by themselves on a screen or with little else. But
> those sort of poly counts in a typical mod that normally has a number of
> players/npcs is going to degrade quickly. It all depends what you're
> doing.
> That degree of detail could fit your project if it's outside the norm of
> an
> FPS mod. Just be aware what the engine was designed and built to do, as
> that
> is the reason for the limitations it has. Short of engine level
> modifications, which you can't do without getting the engine source,
> you'll
> have to stick within those limits, and work around them if possible. Split
> the model into pieces and attach them and stuff like that is probably the
> direction you need to look at to keep that detail level and stay within
> limits.
>
> J
>
> On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
>
> > You send valve a check for $1 mil and you get the source code for it.
> >
> > Any chance we could see a render of it. Got me interested. :D
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > Sent: Thursday, January 31, 2008 5:19 AM
> > To: hlcoders@list.valvesoftware.com
> > Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic
> > buffer
> > (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Well, it's a pretty detailed model with a lot of armor and accessories.
> > I'm
> > happy with the model at about 11,000 polys but when I bring it down to
> > around 5,000 to make it work in game it starts to look pretty bad. Polys
> > get
> > removed from spots where they need to be, such as his eyes. So, you said
> > you
> > can't change it without recompiling Hammer and the engine? How would I
> go
> > about doing that?
> >
> > Thanks for the help Mark.
> >
> >
> > On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> >
> > > Basically the number is current and max (26791>24576) and your model
> > > detail
> > > is to high and will crash the engine. I don't think you can change it
> > > without recompiling hammer and the engine.
> > >
> > > Why you need that much detail?
> > >
> > >
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > > Sent: Thursday, January 31, 2008 4:52 AM
> > > To: hlcoders@list.valvesoftware.com
> > > Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> > > Tell
> > > a programmer to up VERTEX_BUFFER_SIZE."
> > >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > >  Hello all. This is my first email to the mailing list and I'm writing
> > > because I'm really stuck and hope someone can help me out. When I
> place
> > an
> > > entity and try to load my custom character it causes Hammer to crash
> and
> > > displays this error message:
> > >
> > >  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer
> to
> > > up
> > > VERTEX_BUFFER_SIZE."
> > >
> > > I tried lowering the poly and vertex counts and finally got a model to
> > > load
> > > but is way below the level of detail I need. I tried several versions
> of
> > > the
> > > model with varying poly and vertex counts and noticed that the first
> > > number
> > > in the error message (26791 in this case) would change as the poly and
> > > vert
> > > counts change. Also, the high poly model will load fine in Face Poser.
> > >
> > > I've tried to research the problem online and haven't found anything
> too
> > > helpful. The Valve Wiki says I probably have a bug in my code or
> > content,
> > > which doesn't really help me too much. I also got advice to optimize
> my
> > > map
> > > to reduce the vertices but I ge

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
H.interesting. I'll have to try that. Thanks for the suggestion.

On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]> wrote:

> Well, citadelpart8.mdl from ep2 has 28000 polys and gives the same error
> message in hammer:
> "Too many verts for a dynamic buffer (41468>24576) Tell a programmer to
> up VERTEX_BUFFER_SIZE."
> But it's in game so I guess it is only a limitation of hammer. The model
> will propably load if set at runtime.
> -archy
>
> Jeremy wrote:
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Was just curious about polycount. I realize technically you have too
> many
> > vertices. If vertices were shared enough you could have a large number
> of
> > polygons with a smaller number of vertices, provided you don't run into
> any
> > limit on index buffer size that may be present. In this case the error
> is
> > clearly referring to the vertices. Are the vertices welded/merged where
> > appropriate to reduce them as much as possible without sacrificing poly
> > counts? I don't doubt such high poly models probably work, and possibly
> > pretty well if they are by themselves on a screen or with little else.
> But
> > those sort of poly counts in a typical mod that normally has a number of
> > players/npcs is going to degrade quickly. It all depends what you're
> doing.
> > That degree of detail could fit your project if it's outside the norm of
> an
> > FPS mod. Just be aware what the engine was designed and built to do, as
> that
> > is the reason for the limitations it has. Short of engine level
> > modifications, which you can't do without getting the engine source,
> you'll
> > have to stick within those limits, and work around them if possible.
> Split
> > the model into pieces and attach them and stuff like that is probably
> the
> > direction you need to look at to keep that detail level and stay within
> > limits.
> >
> > J
> >
> > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> >
> >
> >> You send valve a check for $1 mil and you get the source code for it.
> >>
> >> Any chance we could see a render of it. Got me interested. :D
> >>
> >>
> >>
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> >> Sent: Thursday, January 31, 2008 5:19 AM
> >> To: hlcoders@list.valvesoftware.com
> >> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic
> >> buffer
> >> (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> >>
> >> --
> >> [ Picked text/plain from multipart/alternative ]
> >> Well, it's a pretty detailed model with a lot of armor and accessories.
> >> I'm
> >> happy with the model at about 11,000 polys but when I bring it down to
> >> around 5,000 to make it work in game it starts to look pretty bad.
> Polys
> >> get
> >> removed from spots where they need to be, such as his eyes. So, you
> said
> >> you
> >> can't change it without recompiling Hammer and the engine? How would I
> go
> >> about doing that?
> >>
> >> Thanks for the help Mark.
> >>
> >>
> >> On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> Basically the number is current and max (26791>24576) and your model
> >>> detail
> >>> is to high and will crash the engine. I don't think you can change it
> >>> without recompiling hammer and the engine.
> >>>
> >>> Why you need that much detail?
> >>>
> >>>
> >>>
> >>> -Original Message-
> >>> From: [EMAIL PROTECTED]
> >>> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> >>> Sent: Thursday, January 31, 2008 4:52 AM
> >>> To: hlcoders@list.valvesoftware.com
> >>> Subject: [hlcoders] "Too many verts for a dynamic buffer (26791>24576)
> >>> Tell
> >>> a programmer to up VERTEX_BUFFER_SIZE."
> >>>
> >>> --
> >>> [ Picked text/plain from multipart/alternative ]
> >>>  Hello all. This is my first email to the mailing list and I'm writing
> >>> because I'm really stuck and hope someone can help me out. When I
> place
> >>>
> >> an
> >>
> >>> entity and try to load my custom character it causes Hammer to crash
> and
> >>> displays this error message:
> >>>
> >>>  "Too many verts for a dynamic buffer (26791>24576) Tell a programmer
> to
> >>> up
> >>> VERTEX_BUFFER_SIZE."
> >>>
> >>> I tried lowering the poly and vertex counts and finally got a model to
> >>> load
> >>> but is way below the level of detail I need. I tried several versions
> of
> >>> the
> >>> model with varying poly and vertex counts and noticed that the first
> >>> number
> >>> in the error message (26791 in this case) would change as the poly and
> >>> vert
> >>> counts change. Also, the high poly model will load fine in Face Poser.
> >>>
> >>> I've tried to research the problem online and haven't found anything
> too
> >>> helpful. The Valve Wiki says I probably have a bug in my code or
> >>>
> >> content,
> >>
> >>> which doesn't really help me too much. I also got advice to optimize
> my
> >

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Matt Stafford]

--
[ Picked text/plain from multipart/alternative ]
'You send valve a check for $1 mil and you get the source code for it.'
Or, send Epic a check for 850k and get an Unreal 3 license ;)

On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> H.interesting. I'll have to try that. Thanks for the suggestion.
>
> On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]> wrote:
>
> > Well, citadelpart8.mdl from ep2 has 28000 polys and gives the same error
> > message in hammer:
> > "Too many verts for a dynamic buffer (41468>24576) Tell a programmer to
> > up VERTEX_BUFFER_SIZE."
> > But it's in game so I guess it is only a limitation of hammer. The model
> > will propably load if set at runtime.
> > -archy
> >
> > Jeremy wrote:
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Was just curious about polycount. I realize technically you have too
> > many
> > > vertices. If vertices were shared enough you could have a large number
> > of
> > > polygons with a smaller number of vertices, provided you don't run
> into
> > any
> > > limit on index buffer size that may be present. In this case the error
> > is
> > > clearly referring to the vertices. Are the vertices welded/merged
> where
> > > appropriate to reduce them as much as possible without sacrificing
> poly
> > > counts? I don't doubt such high poly models probably work, and
> possibly
> > > pretty well if they are by themselves on a screen or with little else.
> > But
> > > those sort of poly counts in a typical mod that normally has a number
> of
> > > players/npcs is going to degrade quickly. It all depends what you're
> > doing.
> > > That degree of detail could fit your project if it's outside the norm
> of
> > an
> > > FPS mod. Just be aware what the engine was designed and built to do,
> as
> > that
> > > is the reason for the limitations it has. Short of engine level
> > > modifications, which you can't do without getting the engine source,
> > you'll
> > > have to stick within those limits, and work around them if possible.
> > Split
> > > the model into pieces and attach them and stuff like that is probably
> > the
> > > direction you need to look at to keep that detail level and stay
> within
> > > limits.
> > >
> > > J
> > >
> > > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >> You send valve a check for $1 mil and you get the source code for it.
> > >>
> > >> Any chance we could see a render of it. Got me interested. :D
> > >>
> > >>
> > >>
> > >> -Original Message-
> > >> From: [EMAIL PROTECTED]
> > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
> > >> Sent: Thursday, January 31, 2008 5:19 AM
> > >> To: hlcoders@list.valvesoftware.com
> > >> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic
> > >> buffer
> > >> (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> > >>
> > >> --
> > >> [ Picked text/plain from multipart/alternative ]
> > >> Well, it's a pretty detailed model with a lot of armor and
> accessories.
> > >> I'm
> > >> happy with the model at about 11,000 polys but when I bring it down
> to
> > >> around 5,000 to make it work in game it starts to look pretty bad.
> > Polys
> > >> get
> > >> removed from spots where they need to be, such as his eyes. So, you
> > said
> > >> you
> > >> can't change it without recompiling Hammer and the engine? How would
> I
> > go
> > >> about doing that?
> > >>
> > >> Thanks for the help Mark.
> > >>
> > >>
> > >> On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >>> Basically the number is current and max (26791>24576) and your model
> > >>> detail
> > >>> is to high and will crash the engine. I don't think you can change
> it
> > >>> without recompiling hammer and the engine.
> > >>>
> > >>> Why you need that much detail?
> > >>>
> > >>>
> > >>>
> > >>> -Original Message-
> > >>> From: [EMAIL PROTECTED]
> > >>> [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> Mears
> > >>> Sent: Thursday, January 31, 2008 4:52 AM
> > >>> To: hlcoders@list.valvesoftware.com
> > >>> Subject: [hlcoders] "Too many verts for a dynamic buffer
> (26791>24576)
> > >>> Tell
> > >>> a programmer to up VERTEX_BUFFER_SIZE."
> > >>>
> > >>> --
> > >>> [ Picked text/plain from multipart/alternative ]
> > >>>  Hello all. This is my first email to the mailing list and I'm
> writing
> > >>> because I'm really stuck and hope someone can help me out. When I
> > place
> > >>>
> > >> an
> > >>
> > >>> entity and try to load my custom character it causes Hammer to crash
> > and
> > >>> displays this error message:
> > >>>
> > >>>  "Too many verts for a dynamic buffer (26791>24576) Tell a
> programmer
> > to
> > >>> up
> > >>> VERTEX_BUFFER_SIZE."
> > >>>
> > >>> I tried lowering the poly and vertex counts and finally got a model
> to
> > >>> load
> > >>> but is way below the level of detail I need. I tried several
> version

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Tobias Kammersgaard]

--
[ Picked text/plain from multipart/alternative ]
Rumor has it that a Source license is only 200k ;-)

/ProZak


On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> 'You send valve a check for $1 mil and you get the source code for it.'
> Or, send Epic a check for 850k and get an Unreal 3 license ;)
>
> On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > H.interesting. I'll have to try that. Thanks for the suggestion.
> >
> > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]> wrote:
> >
> > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives the same
> error
> > > message in hammer:
> > > "Too many verts for a dynamic buffer (41468>24576) Tell a programmer
> to
> > > up VERTEX_BUFFER_SIZE."
> > > But it's in game so I guess it is only a limitation of hammer. The
> model
> > > will propably load if set at runtime.
> > > -archy
> > >
> > > Jeremy wrote:
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > Was just curious about polycount. I realize technically you have too
> > > many
> > > > vertices. If vertices were shared enough you could have a large
> number
> > > of
> > > > polygons with a smaller number of vertices, provided you don't run
> > into
> > > any
> > > > limit on index buffer size that may be present. In this case the
> error
> > > is
> > > > clearly referring to the vertices. Are the vertices welded/merged
> > where
> > > > appropriate to reduce them as much as possible without sacrificing
> > poly
> > > > counts? I don't doubt such high poly models probably work, and
> > possibly
> > > > pretty well if they are by themselves on a screen or with little
> else.
> > > But
> > > > those sort of poly counts in a typical mod that normally has a
> number
> > of
> > > > players/npcs is going to degrade quickly. It all depends what you're
> > > doing.
> > > > That degree of detail could fit your project if it's outside the
> norm
> > of
> > > an
> > > > FPS mod. Just be aware what the engine was designed and built to do,
> > as
> > > that
> > > > is the reason for the limitations it has. Short of engine level
> > > > modifications, which you can't do without getting the engine source,
> > > you'll
> > > > have to stick within those limits, and work around them if possible.
> > > Split
> > > > the model into pieces and attach them and stuff like that is
> probably
> > > the
> > > > direction you need to look at to keep that detail level and stay
> > within
> > > > limits.
> > > >
> > > > J
> > > >
> > > > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >> You send valve a check for $1 mil and you get the source code for
> it.
> > > >>
> > > >> Any chance we could see a render of it. Got me interested. :D
> > > >>
> > > >>
> > > >>
> > > >> -Original Message-
> > > >> From: [EMAIL PROTECTED]
> > > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> Mears
> > > >> Sent: Thursday, January 31, 2008 5:19 AM
> > > >> To: hlcoders@list.valvesoftware.com
> > > >> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a
> dynamic
> > > >> buffer
> > > >> (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> > > >>
> > > >> --
> > > >> [ Picked text/plain from multipart/alternative ]
> > > >> Well, it's a pretty detailed model with a lot of armor and
> > accessories.
> > > >> I'm
> > > >> happy with the model at about 11,000 polys but when I bring it down
> > to
> > > >> around 5,000 to make it work in game it starts to look pretty bad.
> > > Polys
> > > >> get
> > > >> removed from spots where they need to be, such as his eyes. So, you
> > > said
> > > >> you
> > > >> can't change it without recompiling Hammer and the engine? How
> would
> > I
> > > go
> > > >> about doing that?
> > > >>
> > > >> Thanks for the help Mark.
> > > >>
> > > >>
> > > >> On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >>
> > > >>> Basically the number is current and max (26791>24576) and your
> model
> > > >>> detail
> > > >>> is to high and will crash the engine. I don't think you can change
> > it
> > > >>> without recompiling hammer and the engine.
> > > >>>
> > > >>> Why you need that much detail?
> > > >>>
> > > >>>
> > > >>>
> > > >>> -Original Message-
> > > >>> From: [EMAIL PROTECTED]
> > > >>> [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> > Mears
> > > >>> Sent: Thursday, January 31, 2008 4:52 AM
> > > >>> To: hlcoders@list.valvesoftware.com
> > > >>> Subject: [hlcoders] "Too many verts for a dynamic buffer
> > (26791>24576)
> > > >>> Tell
> > > >>> a programmer to up VERTEX_BUFFER_SIZE."
> > > >>>
> > > >>> --
> > > >>> [ Picked text/plain from multipart/alternative ]
> > > >>>  Hello all. This is my first email to the mailing list and I'm
> > writing
> > > >>> because I'm really stuck and hope someone can help me out. When I
> > > pla

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Matt Stafford]

--
[ Picked text/plain from multipart/alternative ]
300-350k is generally the ballpark when we talk about it over at places like
ModDB

On Jan 31, 2008 10:12 AM, Tobias Kammersgaard <[EMAIL PROTECTED]>
wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Rumor has it that a Source license is only 200k ;-)
>
> /ProZak
>
>
> On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > 'You send valve a check for $1 mil and you get the source code for it.'
> > Or, send Epic a check for 850k and get an Unreal 3 license ;)
> >
> > On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > H.interesting. I'll have to try that. Thanks for the
> suggestion.
> > >
> > > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]> wrote:
> > >
> > > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives the same
> > error
> > > > message in hammer:
> > > > "Too many verts for a dynamic buffer (41468>24576) Tell a programmer
> > to
> > > > up VERTEX_BUFFER_SIZE."
> > > > But it's in game so I guess it is only a limitation of hammer. The
> > model
> > > > will propably load if set at runtime.
> > > > -archy
> > > >
> > > > Jeremy wrote:
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > > Was just curious about polycount. I realize technically you have
> too
> > > > many
> > > > > vertices. If vertices were shared enough you could have a large
> > number
> > > > of
> > > > > polygons with a smaller number of vertices, provided you don't run
> > > into
> > > > any
> > > > > limit on index buffer size that may be present. In this case the
> > error
> > > > is
> > > > > clearly referring to the vertices. Are the vertices welded/merged
> > > where
> > > > > appropriate to reduce them as much as possible without sacrificing
> > > poly
> > > > > counts? I don't doubt such high poly models probably work, and
> > > possibly
> > > > > pretty well if they are by themselves on a screen or with little
> > else.
> > > > But
> > > > > those sort of poly counts in a typical mod that normally has a
> > number
> > > of
> > > > > players/npcs is going to degrade quickly. It all depends what
> you're
> > > > doing.
> > > > > That degree of detail could fit your project if it's outside the
> > norm
> > > of
> > > > an
> > > > > FPS mod. Just be aware what the engine was designed and built to
> do,
> > > as
> > > > that
> > > > > is the reason for the limitations it has. Short of engine level
> > > > > modifications, which you can't do without getting the engine
> source,
> > > > you'll
> > > > > have to stick within those limits, and work around them if
> possible.
> > > > Split
> > > > > the model into pieces and attach them and stuff like that is
> > probably
> > > > the
> > > > > direction you need to look at to keep that detail level and stay
> > > within
> > > > > limits.
> > > > >
> > > > > J
> > > > >
> > > > > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > >> You send valve a check for $1 mil and you get the source code for
> > it.
> > > > >>
> > > > >> Any chance we could see a render of it. Got me interested. :D
> > > > >>
> > > > >>
> > > > >>
> > > > >> -Original Message-
> > > > >> From: [EMAIL PROTECTED]
> > > > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> > Mears
> > > > >> Sent: Thursday, January 31, 2008 5:19 AM
> > > > >> To: hlcoders@list.valvesoftware.com
> > > > >> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a
> > dynamic
> > > > >> buffer
> > > > >> (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> > > > >>
> > > > >> --
> > > > >> [ Picked text/plain from multipart/alternative ]
> > > > >> Well, it's a pretty detailed model with a lot of armor and
> > > accessories.
> > > > >> I'm
> > > > >> happy with the model at about 11,000 polys but when I bring it
> down
> > > to
> > > > >> around 5,000 to make it work in game it starts to look pretty
> bad.
> > > > Polys
> > > > >> get
> > > > >> removed from spots where they need to be, such as his eyes. So,
> you
> > > > said
> > > > >> you
> > > > >> can't change it without recompiling Hammer and the engine? How
> > would
> > > I
> > > > go
> > > > >> about doing that?
> > > > >>
> > > > >> Thanks for the help Mark.
> > > > >>
> > > > >>
> > > > >> On Jan 30, 2008 12:06 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > > > >>
> > > > >>
> > > > >>> Basically the number is current and max (26791>24576) and your
> > model
> > > > >>> detail
> > > > >>> is to high and will crash the engine. I don't think you can
> change
> > > it
> > > > >>> without recompiling hammer and the engine.
> > > > >>>
> > > > >>> Why you need that much detail?
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> -Original Message-
> > > > >>> From: [EMAIL PROTECTED]
> > > > >>> [mailto:[EMAIL PROTECTED] On Behalf Of Be

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
That's how much it cost to buy the license to be able to develop and
distribute games commercially right?

On Jan 30, 2008 3:47 PM, Matt Stafford <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> 300-350k is generally the ballpark when we talk about it over at places
> like
> ModDB
>
> On Jan 31, 2008 10:12 AM, Tobias Kammersgaard <
> [EMAIL PROTECTED]>
> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Rumor has it that a Source license is only 200k ;-)
> >
> > /ProZak
> >
> >
> > On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > 'You send valve a check for $1 mil and you get the source code for
> it.'
> > > Or, send Epic a check for 850k and get an Unreal 3 license ;)
> > >
> > > On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
> > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > H.interesting. I'll have to try that. Thanks for the
> > suggestion.
> > > >
> > > > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives the same
> > > error
> > > > > message in hammer:
> > > > > "Too many verts for a dynamic buffer (41468>24576) Tell a
> programmer
> > > to
> > > > > up VERTEX_BUFFER_SIZE."
> > > > > But it's in game so I guess it is only a limitation of hammer. The
> > > model
> > > > > will propably load if set at runtime.
> > > > > -archy
> > > > >
> > > > > Jeremy wrote:
> > > > > > --
> > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > Was just curious about polycount. I realize technically you have
> > too
> > > > > many
> > > > > > vertices. If vertices were shared enough you could have a large
> > > number
> > > > > of
> > > > > > polygons with a smaller number of vertices, provided you don't
> run
> > > > into
> > > > > any
> > > > > > limit on index buffer size that may be present. In this case the
> > > error
> > > > > is
> > > > > > clearly referring to the vertices. Are the vertices
> welded/merged
> > > > where
> > > > > > appropriate to reduce them as much as possible without
> sacrificing
> > > > poly
> > > > > > counts? I don't doubt such high poly models probably work, and
> > > > possibly
> > > > > > pretty well if they are by themselves on a screen or with little
> > > else.
> > > > > But
> > > > > > those sort of poly counts in a typical mod that normally has a
> > > number
> > > > of
> > > > > > players/npcs is going to degrade quickly. It all depends what
> > you're
> > > > > doing.
> > > > > > That degree of detail could fit your project if it's outside the
> > > norm
> > > > of
> > > > > an
> > > > > > FPS mod. Just be aware what the engine was designed and built to
> > do,
> > > > as
> > > > > that
> > > > > > is the reason for the limitations it has. Short of engine level
> > > > > > modifications, which you can't do without getting the engine
> > source,
> > > > > you'll
> > > > > > have to stick within those limits, and work around them if
> > possible.
> > > > > Split
> > > > > > the model into pieces and attach them and stuff like that is
> > > probably
> > > > > the
> > > > > > direction you need to look at to keep that detail level and stay
> > > > within
> > > > > > limits.
> > > > > >
> > > > > > J
> > > > > >
> > > > > > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >
> > > > > >> You send valve a check for $1 mil and you get the source code
> for
> > > it.
> > > > > >>
> > > > > >> Any chance we could see a render of it. Got me interested. :D
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> -Original Message-
> > > > > >> From: [EMAIL PROTECTED]
> > > > > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ben
> > > Mears
> > > > > >> Sent: Thursday, January 31, 2008 5:19 AM
> > > > > >> To: hlcoders@list.valvesoftware.com
> > > > > >> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a
> > > dynamic
> > > > > >> buffer
> > > > > >> (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> > > > > >>
> > > > > >> --
> > > > > >> [ Picked text/plain from multipart/alternative ]
> > > > > >> Well, it's a pretty detailed model with a lot of armor and
> > > > accessories.
> > > > > >> I'm
> > > > > >> happy with the model at about 11,000 polys but when I bring it
> > down
> > > > to
> > > > > >> around 5,000 to make it work in game it starts to look pretty
> > bad.
> > > > > Polys
> > > > > >> get
> > > > > >> removed from spots where they need to be, such as his eyes. So,
> > you
> > > > > said
> > > > > >> you
> > > > > >> can't change it without recompiling Hammer and the engine? How
> > > would
> > > > I
> > > > > go
> > > > > >> about doing that?
> > > > > >>
> > > > > >> Thanks for the help Mark.
> > > > > >>
> > > > > >>
> > > > > >> On Jan 30, 2008 12:06 PM, Mark

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jeremy]

--
[ Picked text/plain from multipart/alternative ]
Yes. And likely includes a royalty rate to valve. There may be alternative
royalty free options that cost significantly more. Few game engines
advertise such things as openly as Epic lists the UE2.5 license costs

On Jan 30, 2008 3:56 PM, Ben Mears <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> That's how much it cost to buy the license to be able to develop and
> distribute games commercially right?
>
> On Jan 30, 2008 3:47 PM, Matt Stafford <[EMAIL PROTECTED]> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > 300-350k is generally the ballpark when we talk about it over at places
> > like
> > ModDB
> >
> > On Jan 31, 2008 10:12 AM, Tobias Kammersgaard <
> > [EMAIL PROTECTED]>
> > wrote:
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Rumor has it that a Source license is only 200k ;-)
> > >
> > > /ProZak
> > >
> > >
> > > On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > 'You send valve a check for $1 mil and you get the source code for
> > it.'
> > > > Or, send Epic a check for 850k and get an Unreal 3 license ;)
> > > >
> > > > On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > > H.interesting. I'll have to try that. Thanks for the
> > > suggestion.
> > > > >
> > > > > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives the
> same
> > > > error
> > > > > > message in hammer:
> > > > > > "Too many verts for a dynamic buffer (41468>24576) Tell a
> > programmer
> > > > to
> > > > > > up VERTEX_BUFFER_SIZE."
> > > > > > But it's in game so I guess it is only a limitation of hammer.
> The
> > > > model
> > > > > > will propably load if set at runtime.
> > > > > > -archy
> > > > > >
> > > > > > Jeremy wrote:
> > > > > > > --
> > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > Was just curious about polycount. I realize technically you
> have
> > > too
> > > > > > many
> > > > > > > vertices. If vertices were shared enough you could have a
> large
> > > > number
> > > > > > of
> > > > > > > polygons with a smaller number of vertices, provided you don't
> > run
> > > > > into
> > > > > > any
> > > > > > > limit on index buffer size that may be present. In this case
> the
> > > > error
> > > > > > is
> > > > > > > clearly referring to the vertices. Are the vertices
> > welded/merged
> > > > > where
> > > > > > > appropriate to reduce them as much as possible without
> > sacrificing
> > > > > poly
> > > > > > > counts? I don't doubt such high poly models probably work, and
> > > > > possibly
> > > > > > > pretty well if they are by themselves on a screen or with
> little
> > > > else.
> > > > > > But
> > > > > > > those sort of poly counts in a typical mod that normally has a
> > > > number
> > > > > of
> > > > > > > players/npcs is going to degrade quickly. It all depends what
> > > you're
> > > > > > doing.
> > > > > > > That degree of detail could fit your project if it's outside
> the
> > > > norm
> > > > > of
> > > > > > an
> > > > > > > FPS mod. Just be aware what the engine was designed and built
> to
> > > do,
> > > > > as
> > > > > > that
> > > > > > > is the reason for the limitations it has. Short of engine
> level
> > > > > > > modifications, which you can't do without getting the engine
> > > source,
> > > > > > you'll
> > > > > > > have to stick within those limits, and work around them if
> > > possible.
> > > > > > Split
> > > > > > > the model into pieces and attach them and stuff like that is
> > > > probably
> > > > > > the
> > > > > > > direction you need to look at to keep that detail level and
> stay
> > > > > within
> > > > > > > limits.
> > > > > > >
> > > > > > > J
> > > > > > >
> > > > > > > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]>
> wrote:
> > > > > > >
> > > > > > >
> > > > > > >> You send valve a check for $1 mil and you get the source code
> > for
> > > > it.
> > > > > > >>
> > > > > > >> Any chance we could see a render of it. Got me interested. :D
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> -Original Message-
> > > > > > >> From: [EMAIL PROTECTED]
> > > > > > >> [mailto:[EMAIL PROTECTED] On Behalf Of
> Ben
> > > > Mears
> > > > > > >> Sent: Thursday, January 31, 2008 5:19 AM
> > > > > > >> To: hlcoders@list.valvesoftware.com
> > > > > > >> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a
> > > > dynamic
> > > > > > >> buffer
> > > > > > >> (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> > > > > > >>
> > > > > > >> --
> > > > > > >> [ Picked text/plain from multipart/alternative ]
> > > > > > >> Well, it's a pretty detailed model with a lot of armor and
> > > > > 

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
Do you guys know of any indie companies that use Source or Unreal licenses
to create and sell their games/mods? Is it common?

On Jan 30, 2008 4:02 PM, Jeremy <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Yes. And likely includes a royalty rate to valve. There may be alternative
> royalty free options that cost significantly more. Few game engines
> advertise such things as openly as Epic lists the UE2.5 license costs
>
> On Jan 30, 2008 3:56 PM, Ben Mears <[EMAIL PROTECTED]> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > That's how much it cost to buy the license to be able to develop and
> > distribute games commercially right?
> >
> > On Jan 30, 2008 3:47 PM, Matt Stafford <[EMAIL PROTECTED]> wrote:
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > 300-350k is generally the ballpark when we talk about it over at
> places
> > > like
> > > ModDB
> > >
> > > On Jan 31, 2008 10:12 AM, Tobias Kammersgaard <
> > > [EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > Rumor has it that a Source license is only 200k ;-)
> > > >
> > > > /ProZak
> > > >
> > > >
> > > > On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > > 'You send valve a check for $1 mil and you get the source code for
> > > it.'
> > > > > Or, send Epic a check for 850k and get an Unreal 3 license ;)
> > > > >
> > > > > On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > --
> > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > H.interesting. I'll have to try that. Thanks for the
> > > > suggestion.
> > > > > >
> > > > > > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]>
> wrote:
> > > > > >
> > > > > > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives the
> > same
> > > > > error
> > > > > > > message in hammer:
> > > > > > > "Too many verts for a dynamic buffer (41468>24576) Tell a
> > > programmer
> > > > > to
> > > > > > > up VERTEX_BUFFER_SIZE."
> > > > > > > But it's in game so I guess it is only a limitation of hammer.
> > The
> > > > > model
> > > > > > > will propably load if set at runtime.
> > > > > > > -archy
> > > > > > >
> > > > > > > Jeremy wrote:
> > > > > > > > --
> > > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > > Was just curious about polycount. I realize technically you
> > have
> > > > too
> > > > > > > many
> > > > > > > > vertices. If vertices were shared enough you could have a
> > large
> > > > > number
> > > > > > > of
> > > > > > > > polygons with a smaller number of vertices, provided you
> don't
> > > run
> > > > > > into
> > > > > > > any
> > > > > > > > limit on index buffer size that may be present. In this case
> > the
> > > > > error
> > > > > > > is
> > > > > > > > clearly referring to the vertices. Are the vertices
> > > welded/merged
> > > > > > where
> > > > > > > > appropriate to reduce them as much as possible without
> > > sacrificing
> > > > > > poly
> > > > > > > > counts? I don't doubt such high poly models probably work,
> and
> > > > > > possibly
> > > > > > > > pretty well if they are by themselves on a screen or with
> > little
> > > > > else.
> > > > > > > But
> > > > > > > > those sort of poly counts in a typical mod that normally has
> a
> > > > > number
> > > > > > of
> > > > > > > > players/npcs is going to degrade quickly. It all depends
> what
> > > > you're
> > > > > > > doing.
> > > > > > > > That degree of detail could fit your project if it's outside
> > the
> > > > > norm
> > > > > > of
> > > > > > > an
> > > > > > > > FPS mod. Just be aware what the engine was designed and
> built
> > to
> > > > do,
> > > > > > as
> > > > > > > that
> > > > > > > > is the reason for the limitations it has. Short of engine
> > level
> > > > > > > > modifications, which you can't do without getting the engine
> > > > source,
> > > > > > > you'll
> > > > > > > > have to stick within those limits, and work around them if
> > > > possible.
> > > > > > > Split
> > > > > > > > the model into pieces and attach them and stuff like that is
> > > > > probably
> > > > > > > the
> > > > > > > > direction you need to look at to keep that detail level and
> > stay
> > > > > > within
> > > > > > > > limits.
> > > > > > > >
> > > > > > > > J
> > > > > > > >
> > > > > > > > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PROTECTED]>
> > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >> You send valve a check for $1 mil and you get the source
> code
> > > for
> > > > > it.
> > > > > > > >>
> > > > > > > >> Any chance we could see a render of it. Got me interested.
> :D
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> -Original Message-
> > > > > > > >> From: [EMAIL PROTECTED]
> > > > > >

RE: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Mike Durand]

I heard there is this guy named Garry who made a Source mod and sold it on 
Steam. ;)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Mears
Sent: Wednesday, January 30, 2008 4:08 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer 
(26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

--
[ Picked text/plain from multipart/alternative ]
Do you guys know of any indie companies that use Source or Unreal licenses
to create and sell their games/mods? Is it common?

On Jan 30, 2008 4:02 PM, Jeremy <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> Yes. And likely includes a royalty rate to valve. There may be alternative
> royalty free options that cost significantly more. Few game engines
> advertise such things as openly as Epic lists the UE2.5 license costs
>
> On Jan 30, 2008 3:56 PM, Ben Mears <[EMAIL PROTECTED]> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > That's how much it cost to buy the license to be able to develop and
> > distribute games commercially right?
> >
> > On Jan 30, 2008 3:47 PM, Matt Stafford <[EMAIL PROTECTED]> wrote:
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > 300-350k is generally the ballpark when we talk about it over at
> places
> > > like
> > > ModDB
> > >
> > > On Jan 31, 2008 10:12 AM, Tobias Kammersgaard <
> > > [EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > Rumor has it that a Source license is only 200k ;-)
> > > >
> > > > /ProZak
> > > >
> > > >
> > > > On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > > 'You send valve a check for $1 mil and you get the source code for
> > > it.'
> > > > > Or, send Epic a check for 850k and get an Unreal 3 license ;)
> > > > >
> > > > > On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > --
> > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > H.interesting. I'll have to try that. Thanks for the
> > > > suggestion.
> > > > > >
> > > > > > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]>
> wrote:
> > > > > >
> > > > > > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives the
> > same
> > > > > error
> > > > > > > message in hammer:
> > > > > > > "Too many verts for a dynamic buffer (41468>24576) Tell a
> > > programmer
> > > > > to
> > > > > > > up VERTEX_BUFFER_SIZE."
> > > > > > > But it's in game so I guess it is only a limitation of hammer.
> > The
> > > > > model
> > > > > > > will propably load if set at runtime.
> > > > > > > -archy
> > > > > > >
> > > > > > > Jeremy wrote:
> > > > > > > > --
> > > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > > Was just curious about polycount. I realize technically you
> > have
> > > > too
> > > > > > > many
> > > > > > > > vertices. If vertices were shared enough you could have a
> > large
> > > > > number
> > > > > > > of
> > > > > > > > polygons with a smaller number of vertices, provided you
> don't
> > > run
> > > > > > into
> > > > > > > any
> > > > > > > > limit on index buffer size that may be present. In this case
> > the
> > > > > error
> > > > > > > is
> > > > > > > > clearly referring to the vertices. Are the vertices
> > > welded/merged
> > > > > > where
> > > > > > > > appropriate to reduce them as much as possible without
> > > sacrificing
> > > > > > poly
> > > > > > > > counts? I don't doubt such high poly models probably work,
> and
> > > > > > possibly
> > > > > > > > pretty well if they are by themselves on a screen or with
> > little
> > > > > else.
> > > > > > > But
> > > > > > > > those sort of poly counts in a typical mod that normally has
> a
> > > > > number
> > > > > > of
> > > > > > > > players/npcs is going to degrade quickly. It all depends
> what
> > > > you're
> > > > > > > doing.
> > > > > > > > That degree of detail could fit your project if it's outside
> > the
> > > > > norm
> > > > > > of
> > > > > > > an
> > > > > > > > FPS mod. Just be aware what the engine was designed and
> built
> > to
> > > > do,
> > > > > > as
> > > > > > > that
> > > > > > > > is the reason for the limitations it has. Short of engine
> > level
> > > > > > > > modifications, which you can't do without getting the engine
> > > > source,
> > > > > > > you'll
> > > > > > > > have to stick within those limits, and work around them if
> > > > possible.
> > > > > > > Split
> > > > > > > > the model into pieces and attach them and stuff like that is
> > > > > probably
> > > > > > > the
> > > > > > > > direction you need to look at to keep that detail level and
> > stay
> > > > > > within
> > > > > > > > limits.
> > > > > > > >
> > > > > > > > J
> > > > > > > >
> > > > > > > > On Jan 30, 2008 12:55 PM, Mark Chandler <[EMAIL PRO

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Ben Mears]

--
[ Picked text/plain from multipart/alternative ]
ha ha, oh yeah, duh. So that means he dropped the big bucks to be able to do
that right?

On Jan 30, 2008 4:18 PM, Mike Durand <[EMAIL PROTECTED]> wrote:

> I heard there is this guy named Garry who made a Source mod and sold it on
> Steam. ;)
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Ben Mears
> Sent: Wednesday, January 30, 2008 4:08 PM
> To: hlcoders@list.valvesoftware.com
> Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic
> buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
>
> --
> [ Picked text/plain from multipart/alternative ]
> Do you guys know of any indie companies that use Source or Unreal licenses
> to create and sell their games/mods? Is it common?
>
> On Jan 30, 2008 4:02 PM, Jeremy <[EMAIL PROTECTED]> wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Yes. And likely includes a royalty rate to valve. There may be
> alternative
> > royalty free options that cost significantly more. Few game engines
> > advertise such things as openly as Epic lists the UE2.5 license costs
> >
> > On Jan 30, 2008 3:56 PM, Ben Mears <[EMAIL PROTECTED]> wrote:
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > That's how much it cost to buy the license to be able to develop and
> > > distribute games commercially right?
> > >
> > > On Jan 30, 2008 3:47 PM, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > 300-350k is generally the ballpark when we talk about it over at
> > places
> > > > like
> > > > ModDB
> > > >
> > > > On Jan 31, 2008 10:12 AM, Tobias Kammersgaard <
> > > > [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > > Rumor has it that a Source license is only 200k ;-)
> > > > >
> > > > > /ProZak
> > > > >
> > > > >
> > > > > On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > --
> > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > 'You send valve a check for $1 mil and you get the source code
> for
> > > > it.'
> > > > > > Or, send Epic a check for 850k and get an Unreal 3 license ;)
> > > > > >
> > > > > > On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > > --
> > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > H.interesting. I'll have to try that. Thanks for the
> > > > > suggestion.
> > > > > > >
> > > > > > > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]>
> > wrote:
> > > > > > >
> > > > > > > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives
> the
> > > same
> > > > > > error
> > > > > > > > message in hammer:
> > > > > > > > "Too many verts for a dynamic buffer (41468>24576) Tell a
> > > > programmer
> > > > > > to
> > > > > > > > up VERTEX_BUFFER_SIZE."
> > > > > > > > But it's in game so I guess it is only a limitation of
> hammer.
> > > The
> > > > > > model
> > > > > > > > will propably load if set at runtime.
> > > > > > > > -archy
> > > > > > > >
> > > > > > > > Jeremy wrote:
> > > > > > > > > --
> > > > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > > > Was just curious about polycount. I realize technically
> you
> > > have
> > > > > too
> > > > > > > > many
> > > > > > > > > vertices. If vertices were shared enough you could have a
> > > large
> > > > > > number
> > > > > > > > of
> > > > > > > > > polygons with a smaller number of vertices, provided you
> > don't
> > > > run
> > > > > > > into
> > > > > > > > any
> > > > > > > > > limit on index buffer size that may be present. In this
> case
> > > the
> > > > > > error
> > > > > > > > is
> > > > > > > > > clearly referring to the vertices. Are the vertices
> > > > welded/merged
> > > > > > > where
> > > > > > > > > appropriate to reduce them as much as possible without
> > > > sacrificing
> > > > > > > poly
> > > > > > > > > counts? I don't doubt such high poly models probably work,
> > and
> > > > > > > possibly
> > > > > > > > > pretty well if they are by themselves on a screen or with
> > > little
> > > > > > else.
> > > > > > > > But
> > > > > > > > > those sort of poly counts in a typical mod that normally
> has
> > a
> > > > > > number
> > > > > > > of
> > > > > > > > > players/npcs is going to degrade quickly. It all depends
> > what
> > > > > you're
> > > > > > > > doing.
> > > > > > > > > That degree of detail could fit your project if it's
> outside
> > > the
> > > > > > norm
> > > > > > > of
> > > > > > > > an
> > > > > > > > > FPS mod. Just be aware what the engine was designed and
> > built
> > > to
> > > > > do,
> > > > > > > as
> > > > > > > > that
> > > > > > > > > is the reason for the limitations it has. Short of engine
> > > level
> > > > > > > > > modifications, which you can't do without getting the
> engine
> > > > > sou

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Jeremy]

--
[ Picked text/plain from multipart/alternative ]
Not necessarily I'd say. It's up to Valve. Unique and interesting mods may
receive special treatment in order to help them out. I don't know if Garry
got a license to the extent that he got engine source and all that, or if he
was just granted the ability to make some money. It could be that Valve saw
a popular mod and saw an opportunity that both Valve and Garry could make
some money. That's purely a guess on my part, but the point is that Valve
can make exceptions if they desire. Typically a commercial game will have to
go the normal licensing route. Since a mod generally doesn't have that
option, the other way in might be to have something so cool, like Gmod, or
Portal, and hope the developer will partner with you for a mutually
beneficial relationship.

J

On Jan 30, 2008 4:24 PM, Ben Mears <[EMAIL PROTECTED]> wrote:

> --
> [ Picked text/plain from multipart/alternative ]
> ha ha, oh yeah, duh. So that means he dropped the big bucks to be able to
> do
> that right?
>
> On Jan 30, 2008 4:18 PM, Mike Durand <[EMAIL PROTECTED]> wrote:
>
> > I heard there is this guy named Garry who made a Source mod and sold it
> on
> > Steam. ;)
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED] On Behalf Of Ben Mears
> > Sent: Wednesday, January 30, 2008 4:08 PM
> > To: hlcoders@list.valvesoftware.com
> > Subject: Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic
> > buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Do you guys know of any indie companies that use Source or Unreal
> licenses
> > to create and sell their games/mods? Is it common?
> >
> > On Jan 30, 2008 4:02 PM, Jeremy <[EMAIL PROTECTED]> wrote:
> >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Yes. And likely includes a royalty rate to valve. There may be
> > alternative
> > > royalty free options that cost significantly more. Few game engines
> > > advertise such things as openly as Epic lists the UE2.5 license costs
> > >
> > > On Jan 30, 2008 3:56 PM, Ben Mears <[EMAIL PROTECTED]> wrote:
> > >
> > > > --
> > > > [ Picked text/plain from multipart/alternative ]
> > > > That's how much it cost to buy the license to be able to develop and
> > > > distribute games commercially right?
> > > >
> > > > On Jan 30, 2008 3:47 PM, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > --
> > > > > [ Picked text/plain from multipart/alternative ]
> > > > > 300-350k is generally the ballpark when we talk about it over at
> > > places
> > > > > like
> > > > > ModDB
> > > > >
> > > > > On Jan 31, 2008 10:12 AM, Tobias Kammersgaard <
> > > > > [EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > --
> > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > Rumor has it that a Source license is only 200k ;-)
> > > > > >
> > > > > > /ProZak
> > > > > >
> > > > > >
> > > > > > On 30/01/2008, Matt Stafford <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > --
> > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > 'You send valve a check for $1 mil and you get the source code
> > for
> > > > > it.'
> > > > > > > Or, send Epic a check for 850k and get an Unreal 3 license ;)
> > > > > > >
> > > > > > > On Jan 31, 2008 9:15 AM, Ben Mears <[EMAIL PROTECTED]>
> wrote:
> > > > > > >
> > > > > > > > --
> > > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > > H.interesting. I'll have to try that. Thanks for the
> > > > > > suggestion.
> > > > > > > >
> > > > > > > > On Jan 30, 2008 1:23 PM, Julian Moschüring <[EMAIL PROTECTED]>
> > > wrote:
> > > > > > > >
> > > > > > > > > Well, citadelpart8.mdl from ep2 has 28000 polys and gives
> > the
> > > > same
> > > > > > > error
> > > > > > > > > message in hammer:
> > > > > > > > > "Too many verts for a dynamic buffer (41468>24576) Tell a
> > > > > programmer
> > > > > > > to
> > > > > > > > > up VERTEX_BUFFER_SIZE."
> > > > > > > > > But it's in game so I guess it is only a limitation of
> > hammer.
> > > > The
> > > > > > > model
> > > > > > > > > will propably load if set at runtime.
> > > > > > > > > -archy
> > > > > > > > >
> > > > > > > > > Jeremy wrote:
> > > > > > > > > > --
> > > > > > > > > > [ Picked text/plain from multipart/alternative ]
> > > > > > > > > > Was just curious about polycount. I realize technically
> > you
> > > > have
> > > > > > too
> > > > > > > > > many
> > > > > > > > > > vertices. If vertices were shared enough you could have
> a
> > > > large
> > > > > > > number
> > > > > > > > > of
> > > > > > > > > > polygons with a smaller number of vertices, provided you
> > > don't
> > > > > run
> > > > > > > > into
> > > > > > > > > any
> > > > > > > > > > limit on index buffer size that may be present. In this
> > case
> > > > the
> > > > > > > error
> > > > > > > > > is
> > > > > > > > > > clearly referring to the vertic

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Tom Leighton]

No, garry got the full engine source (Although he hasnt compiled any
custom engine dll's yet.

--- REMOVED THE PAST CONTENT... it was rather huge! :P ---

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] RE: [hlcoders] "Too many verts for a dynamic buffer (26791>24576) Tell a programmer to up VERTEX_BUFFER_SIZE."

[Matt Stafford]

--
[ Picked text/plain from multipart/alternative ]
IIRC Garry and Valve had a 50/50 agreement (or something like that, maybe he
can clarify), where Valve gave him an engine license for free, but get 50%
of from each purchase of GMod. I'd personally love to see more deals made
like this

Not all licensees have to pay royalties. Sometimes they're used instead of a
licensing fee, sometimes its a combination of both (low licensing fee, but
you pay royalties after you sell a certain number of copies), or sometimes
its just a flat fee for the license. Support also varies, some engines are
licensed 'as-is' with no official support, some companies provide entire
teams for support for other companies (somewhere Epic tripped up).

Most indie companies won't license an engine like Source or Unreal due to
the sheer cost of it. Alot of indie games aren'the typical style that these
engines are generally used for, and you'll find most Indie devs focus more
on low production values and don't utilize alot of the main selling points
of these engines (ie facial animation in Source, graphics in Unreal 3) and
can often write their own engine with only what they need for alot cheaper,
or license something like Unigine or one of those, which is very
feature-rich but fairly cheap (although support for those does lack)

For us, it might seem like alot of money (300k-1mil for a license), but for
publisher-backed companies, the engine license is only a drop in the ocean.

On Jan 31, 2008 12:34 PM, Tom Leighton <[EMAIL PROTECTED]> wrote:

> No, garry got the full engine source (Although he hasnt compiled any
> custom engine dll's yet.
>
> --- REMOVED THE PAST CONTENT... it was rather huge! :P ---
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>


--
Matt Stafford (Wraiyth)
http://www.wraiyth.com
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders