カレンダー

04 | 2008/05 | 06
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Eモーション

作品紹介

爆乳エルフちゃん飼育生活
ラブヴィーナス
マーメイドビーチ
午前0時のスナイパーズ
ダークネス・ヒーローズ
3DOL
湯煙混浴露天風呂の罠
痴漢鉄
いけないバスタイム
お兄ちゃんといっしょ♪
ラブセックスライフ
リアル痴漢タイム

月別アーカイブ

RSSフィード

実験中

-------- -------- --------

■ブログ内全記事

 全ての記事を表示する

アクセス解析です

新・リアルタイム3D【萌え】研究所
■ジャンル : 同人 / デジタルフィギュア / リアルタイム3D / エロ
絞り調節
暗い室内から窓の外が眩しい光で白く見えなくなったり、
明るい屋外から暗い室内が良く見えないアレです。
PIC-2008_5_30_絞り調節1

可視レンジを絞って、見えない部分を作る為には、
予め明るさのレンジを余分に確保しておく必要が有ります。
PIC-2008_5_30_可視範囲説明

とはいえ、256しかない光度レンジを半分に削ると
肌の色がかなり見劣りしてしまいます。
モデルデーターもソレ用に作っていませんし、
技術も無いので擬似処理です。

その全てはエロの為に~
FPS(3)
私がFPSに注目している要素は3つ有ります。
1つは先に説明したマウス操作による視点変更の有用性と、主人公への一体感です。
2つ目は海外のFPSゲームに関してで、3つ目はMOD改造です。

日本のゲーム市場と言えば、長らくファミコンであり、
私も多分に漏れずパソコンでゲームをすると言う
発想はなかなか受け入れられませんでした。
パソコンは非常に高価でゲームで遊ぶには勿体無い!とか、
そもそもパソコンで遊べるゲームが売ってない!とか・・・
パソコンのゲームで始めて買ったのはアダルトゲームでした。

その話とは全く関係ないのですが、海外のゲーム市場は日本とは構造が異なり
パソコン用FPSゲームは一定のシェアを得て居るようです。
しかしながら最新の3D技術を駆使したゲーム開発は予算的に厳しいモノが有り、
ゲームの基礎部分を応用した、類似的なFPSゲームの亜種が多数生まれる
結果と成りつつ有るとの事です。

これは日本でスーパーマリオが大ヒットして横スクロールアクションが発展したり、
ストリートファイター2が大ヒットして同様のルールを用いた格闘ゲームが
大量に出てきた現象と類似する物であると考えています。
流行り、ユーザーが求め、商品が開発され、市場が潤って行く構造は
メーカーとユーザーが一体となって発展してきたと言えるのでは無いでしょうか。

市場構造も面白いのですが、ゲームの制作方法その物も興味を惹かれます。
日本のゲームベンダーの様に、すべてを自社技術で賄うのではなく、
ゲームの基礎部分と成る3Dエンジンや、キャラクターやアイテムの制御を行う
ゲームエンジンの部分を社外から導入するスタイルが実現しています。

極端に言えば、RPGツクールみたいな物を使ってドラクエを作ってる訳です。
前述のストリートファイター2の二番煎じやドラクエのパクリを
ゼロから再生産するのは効率的ではないので、基礎部分は買ってきて
独自の味付けをして売り出すのです。
自社で開発しても基本的な部分が大差なければ、
(或いは基礎部分を開発するに十分な技術力や資金が無ければ)
買って来たエンジンで制作するのは理に適った話です。
新・関節技!
PIC-2008_5_29-3_20_10_IK風操作

従来のボーン制御は、マウスカーソルにボーンを向ける
引っぱる処理だったのですが、
今度は押して回したり、捻ったりします。
これを複数のボーンを連動させながら処理するので、
変な方向に曲がったり、痙攣したり、データーの誤差でズレてしまったり
頭の中は大混乱です。

処理は複雑でも操作は単純なので、違和感無く自然に動く筈です!
新素体も一緒に実験中です。
■胸揺れの追及
もっとリアルな胸の変形を行いたいとか、
胸の動きに対して乳首を上に向けたい、といった場合に
手段としては以下の様な方式が考えられます。
 ・逆パラメーター
 ・逆ボーン
 ・逆重力
 ・親子関係を捨てる
 ・ターゲットボーン
 ・モーフィング変形
これらに付いて個別に説明したいと思います。


・逆パラメーター
胸の揺れは大きくは、(1)動作に対する慣性の影響と、(2)元の形状に戻ろうとする力と、
(3)摩擦損失による慣性の減衰効果のバランスで成り立っています。
このうち、(1)の係数にマイナスを与える事で、
可動の際の乳揺れの方向を逆にする事が可能です。
しかしこの場合、移動で乳が揺れた影響で、更に大きな移動が発生し、
それがより強い慣性を生み出す結果と成り、無限に加速していきます。
ロジックの都合上、パラメーターにマイナスを入れると正常に動きません。
PIC-2008_5_30_胸慣性



・逆ボーン
先端付近を固定して、根元や中央部を大きく稼動させたい場合、
乳首の方向から胴体に向かって、通常とは逆にボーンを埋設させる方法もあります。

ただし、この方法では形状の調整が非常に困難になり、
変形による形状の崩れが大きくダイナミックな乳揺れには適していません。
PIC-2008_5_30_胸慣性2

PIC-2006_3_15-0_22_20.jpg


・逆重力
現在この方式を採用しています。
重力で垂れ下がる際には逆に上を向ける事が可能です。
しかし、揺れに関しては従来同様の、先端ほど影響が大きい処理に成ってしまう為、
狙い通りの変形を実現するには至りません。

この変形のもっとも大きな問題は、後述するボーンウェイトに起因する
ボーンがS時変形した際の形状の整合性が非常に取り辛い点に有ります。


・親子関係を捨てる
根元のみを胸ボーンで変形させて、先端部分は胴体のウェイトを与えれば、
先端は位置を維持して中央部が揺れる動きも出来きます。
全く動かないのも不自然なので、少しだけ揺れる先端用胸ボーンを
胴体から直結して制御すると良い感じに成ります。

この方式の欠点はウェイトです。
親子関係を持たない胸基部と先端部分のボーンウェイトを自然に繋げる
術が有りません。
ローポリゴンならばソコソコの変形が出来ますが、ポリゴン数が多いと
露骨にココから曲がってますーな感じに成ってしまいます。


・ターゲットボーン
眼球の視線操作の際に使用した
ターゲットボーンを用いて追跡させる方法も有ります。
胴体の子ボーンとして胸の前方にターゲット用のボーンを配置し、
胸の先端ボーンはそのボーンをターゲットとして追跡する様に指定すれば、
胸の基部が下を向いた際には上を、上を向いた際には下を向かせる事が可能です。


・モーフィング変形
変形後の形状を直接モデリングする事により、意図通りの胸形状が実現出来ます。
ボーン変形と組み合わせることで、更に自然でバリエーション豊かな表現が
可能に成ります。



■現状の仕様の限界と問題点
球形・曲面を滑らかに変形させる場合、ボーン変形だけでは限界が有ります。
ボーンの移動・回転による制御では、複数のボーンを用いて変形した場合に
どうしてもボーンの接合部分の変形と、ボーン単体の影響を受けている部分とで
滑らかな形状変化が得られずに、その曲線が不均一な変形と成ってしまう為です。

この問題は寧ろ、ボーンのウェイト配置に限界が有る為とも言えます。
同一方向に曲げた際には大きな違和感として現れる事は無くとも、
「胸が重力で垂れて先端を上に向かせる」等の形状を再現する為に、
胸のボーンがS字に成った際には、このボーンの繋ぎ目とウェイト数値の変化の
境界がハッキリと見て取れます。
また、胸をオッパイカスタムでサイズ調整した際にも、
変形による不自然な繋ぎ目は露出してしまいます。

これらの問題のほかにも、胸の変形に関してはクリアすべき要点が多々有ります。

●要点
 ・自動乳揺れやオッパイカスタムによるサイズ変形に対応する事。
 ・服を着せた時に素体と連携が取れる変形ロジックで有る事。
 ・服や下着類のカスタムパーツ生産が合理的コストで行える事。

胸の変形の違和感は、ウェイトなどを細かく調節すれば
目立たなくなるかも知れませんが、
その場合、オッパイカスタムでサイズを変更したり、
服を着せた場合などに問題が出てきます。
モーフィングで胸を変形させた場合も、下着や水着など
胴体にフィットする形状のアイテムを制作する際には
同様のモーフデーターを大量に作成する必要が有り現実的ではなくなってしまいます。

何か1つが実現出来ても、その為に他の部分が犠牲となってしまい、
妥協点を探った落とし所が現在の仕様と成っているのです。

現状で満足している訳では有りませんが、現在の仕様をどう拡張すればよいか
具体的な解決策が見出せないままに、
画期的アイディアが閃くのを待っている様な状態です。

一応今の考えとしては、次回作では
無難な仕様を採用して着せ替えなどに対応した標準素体と、
実験的な機能を盛り込んだ拡張用の素体の二段構えで行こうと考えています。

乳揺れに関してのご意見や、機能の要望とかアイディア募集中です。
画面効果
PIC-2008_5_30_絞り調節機能

リアルな画質とは全然方向性が異なるのですが、
色々面白いエフェクト機能も入れようと考えてます。

処理負荷の面で少々心配なのですが、
設定でON/OFF出来る様にして
要らなければ使わなければ良い思って。
FPS(2)
FPSで最重要要素は入力ディバイスの違いで有るとの認識が有ったので
私はてっきり、マウスで照準を操作するゲーム全般を
FPSと証するので有ると思い込んでいたのです。

厳密に言うと、私がプレイしたのはロボットの背中が見えるタイプなので
FPSでは無かった訳ですが・・・

マウス操作における視点変更は、対戦アクションゲームに用いるには
成れない人にはハードルが高いかも知れませんが、
この視点操作の便利さと爽快感は比較的多くの人に共感してもらえると考えています。

リアルタイム3Dは視点変更が自由に行える事が特徴ですが、
その操作には成れが必要で、煩わしいと考える人も多く居るようです。
このリアルタイム3Dのエッチシステムに、FPSの要素を取り入れて、
自由な視点変更と移動と女の子へのアクションを、視覚的に解りやすく
直感的にも自在に操作出来る様に出来るのではないかと考えています。

なので「FPS的な要素」と言うのは、
次回作でガンシューティングとエロゲーを混ぜた物を作ると言う意味では有りません。
主人公を操作して移動し、マウスで視点をグリグリ向きを変えて
見たり触ったりが直感的に行える、自分がその場に居るかのようなゲームを目指す!
っと言う意味で、敵を倒すアクションゲームにオマケでエロをつける様な
事にな成りません。しません。もうそれは前にやって懲りて反省してます。
ポーズエディタ新機能
今の女性キャラクターのモデルは、
ハイポリゴンモデルに複雑な動きをさせる為に、沢山のボーンが入っています。
それぞれのボーンでピッチやロールを分割して担当するので
ポーズを付けるのは大変です。

ポーズが破綻しない様に回転制限を設けたり、
クリックした際の基本回転方向を制御して、出来るだけ少ない手順で
ポーズを付けられる様に工夫してますが、まだまだ複雑・・・

これをもっと簡単に、引張ったり回したりするだけで
ポーズを付けられる様に秘密機能を実験中です。
PIC-2008_5_28-1_21_47_IK風操作

秘密なのでまだ秘密です。
操作性の改善
ポーズエディタは、当初の予定ではその名が示すとおり、
ポーズを付ける為の物でモーションなどの制作までは考慮して居ませんでした。

高度かつ多機能なものを開発するのは個人製作では難しい事と、
専門的な3Dソフトには機能面で劣るので、
コンセプトを変えて「簡単にポーズを付けて遊べる!」
デジタル可動フィギュア的なポジションを狙ったのです。

もちろん、ポーズを付けたらスクリーンショットを撮影してネットにアップしたり、
そのポーズデーターを交換するなどして、更に広まって発展すれば・・・
との思惑もありました。

ブームとまでは行きませんでしたが
データー投稿をしてくれるユーザーさんも居ますし、
ポーズエディタに関する意見も多く頂く事が出来ましたので
「公開はしなくても個人的に動かして遊ぶ」的な需要も十分に大きいと思います。

そこで、思った以上に需要が有りそうなので、
ポーズエディタの機能の強化を行っています。

機能を増やす一方で、簡単に扱えると言うコンセプトも忘れては成りません。
高度な機能を備えた3Dソフトは既に多数有りますから、
作品内のキャラクターをそのまま簡単に動かして遊べる!という
コンセプトを忘れてしまっては元も子も有りません。
FPS(1)
先日紹介した東京夜ですけど、
海外ではFPSゲームが人気で割とポピュラーらしいです。
詳しく知りませんが・・・

このFPSと言うのは画面の更新回数の事ではなくて
ファーストパーソンシューティングの略で
要は主人公の視点で戦うゲーム全般を指すジャンルの様です。
よく判りませんが・・・

この辺の知識が未熟な為に、以前シューティングゲームを作った際には
FPSじゃないとの指摘を頂いて、ようやく気付いた有様です。
実はFPSやソレ系のゲームに関しては余り詳しくは知りません。

初めてFPS系のネットゲームを見せてもらった際に、
マウスで視点変更する事に衝撃を受けて、とても感動しました。

それまでゲームと言えばゲーム用のコントローラーを用いて
プレイするのが当然だと考えていて、マウスの様に思い通りに素早く動かせない
ディバイスでアクションゲームをプレイする発想は理解出来なかったのです。
敵を正確に狙い打つゲームで、ディバイスの優劣で勝敗が決する様な要素を好ましいとは
考えていないのも一因では有ります。

FPSの特に気に入ったのが視点変更の軽快さで、
それまでのゲーム用のコントローラーを用いた操作でもっとも不満だった、
視点変更の煩わしさと、その事から来る画面の閉塞感が、
マウスを用いた自在な操作に拠って、瞬時に見たい方向を確認できる事により
一気に視野が広がって世界観が掴みやすくなったのです。

3Dゲームで敵に後ろを取られた際に、ゆっくり旋回しながら振り返ってボコボコ
なんて事は無く、素早く振り返る事が出来るのです。
マウスの操作速度=旋回スピードとなってしまうと、旋回速度を考慮した戦術も
後ろを取る有利も無く、ゲームに成らないんじゃ無いかと思ったりもしたのですが、
実際にプレイすると、既存のゲームとは異なる攻略ポイントや遊び方があり、
操作が異なるだけではなく、まったく異なるジャンルのゲームで有る事を
認識させられました。
続・アフィリエイト
あぁ、そうか・・・
サイトの方しかアフィリエイト用に登録してないから
このブログとか退避用のエリアとかカスタム用に確保した領域のページは
アフィリエイトリンク貼ってもダメなんじゃないか?

IDに重複して登録できないのかな・・・?
じゃあアップするサーバーの数だけIDを登録して
ページ管理しろって事か・・・?
ウチみたいにちょくちょく要領不足とかでサイト構成が変わると
その度に再登録して手動でサーバー別にページ分けてURLを手直しして
これはちょっと現実的じゃないな

何か上手い方法が有ればいいんだが・・・
一回元のサーバーを中継させてからDLに飛ばすのかな
それだと肝心の情報が解析出来ないのでアフィリエイトするメリット薄いなぁ

昨日の今日でイキナリだけどもうイイや
アフィリエイトは諦めて作品製作に専念した方がマシだろう
仮タイトル
何時までも次回作と言うのもナンなので、ここらでそろそろ
仮タイトルでも考えたいと思います。
名前が付けば思いいれも変わる筈です!

やはり、前作の二匹目のドジョウを狙った感を全開に発揮して
痴漢鉄2なんてのはドウでしょう!?チカンテツー(笑)なんちゃって・・・
え、ボツですか?はい、そうですね。

では更にパワーアップしたイメージで強姦鉄!アイアンレイプ!
・・・安直ですね。
もう暫く時間を掛けて考えたい所ですが、
前回もそう言いながらズルズルだった記憶が・・・
東京夜(紹介)
RJ039897_img_main.jpg

DLsiteの新着に気に成る注目タイトルが登場してきました。
リアルタイム3Dを用いたゲーム作品の様です。
まだ試してないのですが、一応要注目作品と言う事で予想で紹介します!

海外生産の作品らしく、日本語に翻訳済み。
国産とはまた違った視点で作られていそうな気配で
斬新な何かが期待出来そうな予感がします。
海外製作品と言うのも珍しいのですが、日本語化されている点や
東京が舞台となっているなど意欲的な物を感じます。

どうやらFPS的なシューティングゲームの要素が有るらしく
当サークルとしてもその内容にはとても興味深い所が有ります。
現在当サークルで製作中のゲームも、主観視点で主人公を操って
フィールド上を移動するゲーム要素を持たせようと考えているので、
類似するゲームが出ると先を越されたか!?と思うところも有りますが、
後発としては既出作品の評判や要望意見がネットに出れば、
それを有利に活かす事も出来る点でメリットも有りますから、
出来るだけ情報を収集して開発に活かしたい所です。

Tokyo Night(DLsite.com販売ページ)
http://maniax.dlsite.com/dlaf/=/link/work/aid/groe2/id/RJ039897.html

アフィリエイト
アフィリエイトが始まって暫く経って特に理由も無くマイブームが発生した季節に
多分に漏れず当サークルもアフィリエイトリンクをせっせことこさえた訳だが
いちいちアフィリエイト用のリンクを作成するのが面倒で何時の間にやら
すっかり忘れ去ってしまっていた

実に今更な話だが、痴漢鉄がこんなにヒットするなら、
真面目にアフィリエイトしておけば其れなりの金額に成った筈なので
これは後悔して置かねば成らないだろう!ガッカリだー

リンクしておけば、販売の傾向やリンク元URLに加えて
日にち別にカレンダー表示で販売分布など様々な情報が得られる
Dlsite.comで売れている作品のうちで、
どの程度がHP経由の購買層かも知る事が出来るので
アフィリエイトを利用しているサークルと、そうでないサークルとでは
手持ちの情報にかなりの開きが生じる事と成る

自分で言うのもなんだが、ウチのサイトは結構無駄に複雑で
散らばっているのでリンクを直すのも一苦労する
実際はそれ程の手間でなくとも、
全容の把握しきれない作業は億劫に成りがちだ

つまりサイトの構造をよく覚えていないし
何処に何が書いて有るかなど気にしないし
過去は振り返らない主義だ
要するに面倒くさい

とはいえ、DL戦術分析を行う上で情報収集を疎かにしては
日頃の戦術分析も説得力が失われる
このままでは守銭奴の名も廃ると言うものだ
がめつくガッツリをもりもりアピールしなければ

っと言う事で一念発起して、これからは積極的にアフィリエイトリンクを
頑張ろうと思う次第
脳内会議(5)大宇宙の意思
つまり天空からの電波を感じることで
神の意思を汲み取り、己の役割を認識する事が可能と成り
皆は争う事無く各々の務めに励み幸せが訪れるのです。

エロとは本能であり、作品製作はインスピレーションです。
そこに小難しい理屈を持ち込むのは、所詮小ざかしい知恵をつけたサルの浅はかさ
であって、真理の追究のためには帰って邪魔になるくらいです。理を捨て無と成り、
己が潜在の意識を開放し、大自然の息吹を感じることで、風に靡く稲穂の如く、川の
せせらぎにも似た流れに逆らわない自然体のオーラが発生する。己のエゴを主張した
自然界の法則に反した現在の人間達の歪んだ思想から出る邪悪なるオーラを撃ち滅ぼし
今まさに救世主さま復活の為に地球上の生きとし生けるものオラに元気を分けてくれ。
モーフィングのデーターをUVで
ブログは日々の愚痴とか電波をチマチマ発進する為の物で、
やっぱり、多くの情報を整理して閲覧するには向いてない気がする。

出来ない事は無いけど、大変だ。挫折。
やっぱり普通にテキストに書いて添付した方が作りやすいし見やすい。



・表情の制御
表情の制御にはボーンで動かしたりモーフィングを利用したり
色々な方法が有るのですが、今回は新機能のモーフィングに関してです。
モーフィングは表情意外にも色々使い道が有ります。

ここで問題に成るのは、モーフィングデーターを如何に制作するか、と
そのデーターをどうやって受け渡すかです。
モーフィングを扱えるソフトや、その情報を他のソフトに
移植出来る方法が有れば良いのですが、あまり良い手段が思いつかず
多少回りくどい方法に成ります。

モーフィングのデーターを準備するには、
 A・元と成る表示用ポリゴン形状
 B・元と成るポリゴン形状と同一の形状
 C・BとUV値が同一の変形後の形状
の3つが最低必要に成ります。

Aは従来のボーン変形でも使用している表示用のモデルです。
モーフィングのデーターを作るには、その動作負荷が大きなネックと成りますので
表示用モデル(A)全体を変形させる事は効率的では有りません。
そこで、Aのモデルから、変形させたい部分のみを抽出したBを制作します。

変形は頂点単位で行われますので、変形させたいポリゴン面ではなく、
変形させたい頂点を含む面を残します。
残った面には新しく同一の材質を設定して、UVを割り振っておきます。
このモデルはBとして保存します
AとBの座標を比較する事で、どの頂点が変形の対象であるかを認識します。

肝心なモーフィングの変形情報は、Bを元にして変形させたCとして保存します。
どの頂点が何処へ移動したか?の判断を、UV座標が同一である事で認識します。

頂点の番号で対応を保持すると、編集中に頂点の配列が変わってしまったり、
元のモデルを編集した際に一致が取れなくなってしまい、その度にモーフィングデーター
を再作成する事に成るので、その手間を考えれば、この方法は割と悪くないと思います。
モーフィングの御利用計画・無理の無い変形プラン
モーフィングとボーン変形の連動の機能は表情の制御以外にも、
胸をもっとリアルに変形させたり、腹式呼吸させてみたり、
触手をエロエロな感じで動かすのにも役に立つ筈!

っと思いながら、機能を作るばかりで
肝心の作品本体の制作が後回しなので、そろそろ焦ります。

いや、高く飛ぶ為には一度屈まねば成らないと言いますし
いざ生産が軌道に乗れば速いはず!・・・はず?
脳内会議(4)全体の流れ
トップダウンの体質を改善して~
企業や役所の組織改革でよく聴かれる言葉ですが、
モジュールの一部がブロック構造化して効率を最適化し始めた場合に
ツリー構造の縦型連結が軽視されると、横の連携が失われ
結果として全体の統率が取れなくなりボトルネックモジュールが発生します。

小学校の火災の避難訓練で、先生の指示に従って順番を守って列に並んで~
といわれても、なかなか進まなくてノロノロとしか動かなくて
指示を待って行動するより自分ひとりが走って逃げた方が早そうに思えるものです。
無論皆が走って出口に殺到すれば、全体の非難が遅れて効率は悪く成ります。

現場の独断は非常に危険で、それが全体に悪影響を及ぼさないか?
現場で処理可能な事案か?ボトルアップして再検討すべき事か?
それを判断するのが仕様であり設計コンセプトなのです。
■仕様メモ
このジャンルでは痴漢鉄と試作版の仕様に関しての情報を
暫定的ながらまとめて行きたいと思います。

仕様メモ
http://emo3d.blog26.fc2.com/blog-category-25.html




無闇矢鱈と駄文の多いこのブログは
必要な情報を見つけるのが非常に難しいので
せめて、カテゴリーの記事一覧を表示出来ないかと調べてみました。
画面左下のプラグインに追加しましたが、
結局カテゴリー画面で開いている記事のタイトルしか出てこないので
然程便利には成らなかったみたい・・・
スクリプトの互換性
正直これは痛いです。やっちまった感が///
作品間の互換性を維持したいと考えていまして、
極力仕様は変えない様にと考えていたのですが・・・

エラーチェックや正規表現のチェックが厳しくなってます。

作品のデーターを作っていると、割と「原因不明で動かない!」事が有って、
どこかが間違っているのだろうけど、それがどこか解らない問題に対して
プログラム側でしっかり原因をエラーで出そう!と考えた為です。
今までも不満を感じていた部分なのですが、少しの量なら
問題点を自力で調べる方が速いので何とか我慢してた訳ですが、
今回追加データーの制作をやってるうちに懲りたのと、
ユーザーさんのデーター投稿が盛んだったりして、その辺の強化も行っています。

しかし、その事が思わぬ弊害を招いてしまって
今まで間違ってるけどエラーに成ってなくてギリギリ動いてたデーターが結構あって
それが今回弾かれてしまった形です。
この「害の無いミス」と「有害なミス」の見分けが、プログラム的には出来ないので
これまで問題なく動いてたデーターでも正確に書かないとエラーで止る様に成っちゃった
訳です。

旧作のデーターを作り直して配付するか、デバックモードみたいなスイッチを付けるか
検討の結果、カッコ悪いけどもう一度修正ファイルを出す方が良いと考えてます。
ただ、この修正は新作との互換性の問題なので、旧作向けの修正ファイルではなく
新作に旧作互換パッチとして同封する予定です。
脳内会議(3)現場の判断
これまでユーザーさんからの要望に対して、
「仕様が・・・」とか「当作品の設計コンセプトに~」といった言い訳がましい
返答でお茶を濁す事が多く、要望に対して積極的で無かったと思います。

痴漢鉄辺りからはその辺の改善を目指して、
有る程度小さな修正であれば、現場レベルでの即断即決を行い
機能の強化と、実用に沿った運用が可能な形態を目指してきました。

直ぐに出来そうな改修なら、言い訳を並べて理屈っぽく深く考えるより
さっさと作業して機能を改善した方がユーザーさんも作者も得だという考えです。

実際に様々な意見を頂く事が出来て、ポーズエディタやカスタム機能は
開発中よりも発売後のほうが機能の強化が進んだと思います。
カラーカスタム
下着を作ったときに考えたのですが、
どうにも標準のカラーカスタムだけでは満足できないので、
もっと拡張的なカラーカスタムを付けて、
いろいろな場所を色変更出来るようにしたいなー

・・・とか考えたのが運のつき
簡単に出来ると思った事が簡単に出来た試しは無く
考えの甘さを痛感する学習能力の低さ

毎回こんな調子なので、簡単に思える事でも出来ない気がして
多分~とか、おそらく~みたいな曖昧な返事に成っちゃうんですよね・・・

多分、おそらく、もう直ぐ出来る・・・筈です
脳内会議(2)偉い人の言葉
時に動作効率を、あるいはエロを、制作コストを、ゲームの楽しさを、
脳内にアホが集まって好き勝手にやっていたら1つに纏まりません。
それを纏めるのが設計方針たる企画・仕様書であり
これは脳内序列一位の人からの命令書に等しいので副人格の下っ端は逆らえません。

その機能や仕様変更が、本当に必要で有益であるかの検討を(脳内で)重ねて
設計方針や仕様を修正し、実際の修正作業を行うまでに
非常に長いステップが必要でリアクションタイムを悪くしてきました。
所謂お役所仕事です。
脳内会議(1)もう1人のボク
多重人格とは異なる意味で、
誰しもが心に天使と悪魔を飼っているモノだと思います。

例えば、夏に成れば「早く冬になれ!」と思い
冬に成って寒くなると「暑い方がマシだ!」と思ってしまうみたいな。

作品を1人で作っていると、様々なパートの作業を同一人物がこなす訳で、
それぞれの作業の段階に置いては利害が異なり対立する事も有り得るのです。

食べたら太る!でも食べたい!人生は常に脳内会議なのです。
実写
下着のテクスチャー作るのがスゲー苦手で大変だなーとか思ってて
こんな事ならいっその事下着売り場に特攻して現物入手&撮影して
テクスチャーに加工すれば・・・とか。

しかし、レース模様や下着のデザインには著作権があるので、
これをそのままパクって同じモノを作ったり、
まして撮影して使用するなどしては幾ら親告罪とはいえ
製作者として問題が有る様な気がしないでも無いかも知れない気がする。

でもでも、良く考えたら、
AVなどでは普通にスクール水着や下着が使用されている訳で、
それが問題に成ったらしい話しは聞いた事が無い気がするし。

しかしやはり、映像作品で登場するのは想定される使用の範疇でも
データー化してゲームに含めて配付するのは問題に成るケースは多々有るし、
撮影してデーター化して使用するのはやはり問題が有る気が・・・
でもビデオ撮影でも、撮影後にデーター化して販売する点では同じ気がするし。

いや、でもヤッパリ誰もやってるの見たこと無い様な気がするし、
楽をしたいが為に危ない橋を渡るのはロクな事に成らない気がするし、
技術蓄積の意味でもこの苦労は買ってでもしろと言っている気がする気がする。

つまり下着を買わねば成らない気がする。
■詳細なエラー警告の有無
カスタムモデルを作る際に、何故か動かない様な状態に陥った場合、
この原因がエラーメッセージで得られるとすれば非常に便利な事です。

しかしながら、エラーチェックを行うと曖昧さが許されずに
本来は動作に影響の無い部分までチェックされてしまう恐れも有ります。
コレまで問題なく使えていたデーターでさえエラーが出るかも知れません。

プレイヤー的視点では不要なエラー警告は出ないほうが良い。
しかしカスタムデーターを作る製作者的視点では動かない原因は判ったほうが良い。
この部分はオプションで切り替えが出来るのが理想なので、
その様に検討を進めています。
作品イメージ
あまり厳密に管理してる訳でもないのですが、
一応作品ごとのイメージという事で、背景や枠などの
デザインや色に統一性を持たせよう的な事を(少しだけ)考えてます。

痴漢鉄では、地下の暗さを示す黒を基調とし、
ホームの白線と、日常との境界線とを意図した白のラインに
痴漢行為と言う危険性をイメージした
ギザギザパターンを加えたデザインに成っています。

作品内のインターフェイスに統一性を持たせる意図も有って
作品紹介のWEBデザインなどでもこのパターンを多用しています。

この部分は割と不評を頂いたのでUI関係は改善をしたい所です。

新作ではデザインを変えて、
ココが新しい新機能だって部分をプッシュしたいです。
そうでもしないと、どこが新機能の部分なのか判らない不安も・・・
そもそも思いっきり背景に痴漢鉄って文字入ってますし
作り直さないと・・・です。
表情の可動のテスト
クチ辺りの変形にモーフィングが使われている。
ボーンに連動させて、ボーンをモーションで制御する方式。
胸揺れに合せれば乳形状をコレまで不可能だったリアルな変形も可能になるし、
任意に制御する際に新規のエディタ開発も不要と成り、
体の動きと表情の連携も付けやすい利点も考えられる。



・追記
画像が無かったので追加
PIC-2008_5_17_表情可動2
アニメGIFにすると500KB制限が意外とキツイ・・・
ネットワーク機能
ネットワーク機能を再検討しています。

以前はプロテクトシステムとして開発を進めていた物なのですが、
この部分からネットワーク部のみを

プロテクト無しで動かすと成ると、外部から操作可能な
セキュリティーホールを組み込む様な物ですから、
この部分を切り離すのは・・・

どうも色々無駄な心配ばかりして一歩が踏み出せない性分なので
案ずるより産むが易し、なのか
あるいは取り返しの付かない事になるのか
続・表情の制御システム
課題は大きく分けて4つあります。
 1.どうやって作る?
 2.どうやって読み込む?
 3.どうやって処理する?
 4.どうやって制御する?

無い知恵を絞って、3番は何とか実装の見通しが立ちました。
1・2は天使が降りてくるか電波を受信するまで待ちましょう。
問題は4番です。

制御系は大きく分けて4種類必要です。
 4.1・モーション制御
 4.2・スクリプト制御
 4.3・オートマチック制御
 4.4・ゲーム連動制御

4.1・モーション制御
作品内のムービーシーンなど、動きと連動して細かい表情の変化を表現するには
モーションで表情が動かせる事が理想です。
ボーンに連動したモーフィング機能(アニマス的にはマッスル機能?)を加えて
マブタやクチのボーンと連動させてモーフを行い、モーションで表情を制御します。

4.2・スクリプト制御
モーションで表情を制御するのは、自由度は高いのですが、全編をその方式で
行う事は非常に手間が掛かり困難です。
表情の可変の必要の無いシーンや、会話中に変更させたい場合など、
立ちモーション表情笑い、立ちモーション表情泣き、立ちモーション表情怒り……
と全ての表情バリエーションを×数で制作すると膨大な量に成りますから、
これはスクリプトで表情だけをモーションと別に管理して、個別に指定したいのです。

4.3・オートマチック制御
スクリプトではバッチ処理で表情以外の制御も行う必要が有る為、
リアルタイムに連続的な処理が必要な動作、例えば「まばたき」や
会話中のクチの変形などの処理は、プログラム側で自動的に処理出来る必要が有ります。

4.4・ゲーム連動制御
次回作ではゲームの処理も予定してまして、これもスクリプト上から制御出来ません。
ゲームの進行に合わせて、ダメージを受けたり驚いたりした場合に、
即座に表情を切り替える必要が有る為、ゲーム側からの
表情の制御も出来なくてはいけません。

これらの要求を満たす表情のモーフデーターと、ソレを制御可能な表情制御パラメーター
を同時に実現する為、色々考えてますが、
如何せん次回作のゲーム部分やスクリプトの仕様がまだ固まっていない為、
なかなか作業が進まずにいます。
■メモ
[PR]属性
・p_st_rinkaku_LineSize=0.001
輪郭の太さ(標準0.001)

・p_st_rinkaku_LineSizeType=1
輪郭の処理方式
0:固定値
1:指定値で処理(Default)
2:画面からの距離を考慮して一定に保つ
ただしこの処理は完全ではない。
画面比率に対してではなく、距離で処理される為
カメラのパース変更や並行投影によって意図しない画面に成る場合が有る。
また遠距離時にはキャラクターモデルが線で潰れる問題も残る。

起動時に一度のみ指定できる。
実行中の変更には対応しない。